Subject: Doodle: RADEXT Virtual Interim

From: "Doodle (on behalf of Bernard Aboba)" <[email-masked]>
Date: Thu, 28 Jan 2010 18:55:33 +0100 (CET)

Bernard Aboba invites you to participate in Doodle poll "RADEXT Virtual Interim".

Follow this link to participate in it:
http://www.doodle.com/9huzzmkgi4vrvvrm69cxffix/private
Please note that this is a personal link that cannot be shared with other poll participants.

Get Branded Doodle: your logo (free!) and optionally no ads
http://doodle.com/r/enBrandedDoodle

--
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: "Bernard Aboba" <[email-masked]>
Date: Thu, 28 Jan 2010 16:46:36 -0800

I have gotten some reports that the DOODLE link for the RADEXT Virtual Interim is behaving strangely.  

Try this link instead:
http://www.doodle.com/9huzzmkgi4vrvvrm

Delivery-date: Fri, 29 Jan 2010 00:47:27 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: RE: Doodle: RADEXT Virtual Interim
Date: Thu, 28 Jan 2010 16:46:36 -0800

I have gotten some reports that the DOODLE link for the RADEXT Virtual Interim is behaving strangely.  

Try this link instead:
http://www.doodle.com/9huzzmkgi4vrvvrm

Delivery-date: Thu, 28 Jan 2010 17:56:02 +0000
Date: Thu, 28 Jan 2010 18:55:33 +0100 (CET)
From: "Doodle (on behalf of Bernard Aboba)" <[email-masked]>
Reply-To:  <[email-masked]>
To:  <[email-masked]>
Subject: Doodle: RADEXT Virtual Interim

Delivery-date: Thu, 28 Jan 2010 17:52:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Summary of "Last Look" at the RADIUS Design Guidelines document
Date: Thu, 28 Jan 2010 09:52:56 -0800

------=_NextPart_000_0050_01CA9FFF.AB27CE70
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On December 4, 2009, a "Last Look" at the RADIUS Design Guidelines document
was announced:

http://ops.ietf.org/lists/radiusext/2009/msg00661.html

While the "last look" was to have concluded on December 18, 2009, vigorous
discussion continued well into January 2010. 

This message represents a summary of the "last look", and a proposal for how
to move forward. 

First of all, examination of the "Last Look" discussion indicates that the
document as it stands does not represent RADEXT WG consensus and therefore
will require changes.  

The major areas of concern include:

1. Treatment of complex attributes.   These concerns were raised in Issue
325 and relate to Section 2.1.3 and portions of Appendix A.  Proposals to
move forward are included in the following messages sent to the list: 

                a. http://ops.ietf.org/lists/radiusext/2010/msg00038.html

                b. http://ops.ietf.org/lists/radiusext/2010/msg00080.html

                c. http://ops.ietf.org/lists/radiusext/2010/msg00107.html

2.  Applicability.  These concerns have been raised in Issue 327, and relate
to multiple sections in the document.  Suggestions on how to move forward
have been made by Dan Romascanu in the following message:
http://ops.ietf.org/lists/radiusext/2010/msg00075.html

It is our hope that discussions on the mailing list will result in proposed
text addressing the concerns within the next week.  

In order to provide a venue for additional discussion, we will be posting a
Doodle poll to determine times for a RADEXT Virtual Interim meeting. 

 

------=_NextPart_000_0050_01CA9FFF.AB27CE70
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal>On December 4, 2009, a &quot;Last Look&quot; at the RADIUS
Design Guidelines document was announced:<o:p></o:p></p>

<p class=MsoNormal>http://ops.ietf.org/lists/radiusext/2009/msg00661.html<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>While the &quot;last look&quot; was to have concluded on
December 18, 2009, vigorous discussion continued well into January 2010. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>This message represents a summary of the &quot;last
look&quot;, and a proposal for how to move forward. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>First of all, examination of the &quot;Last Look&quot;
discussion indicates that the document as it stands does <b>not</b> represent
RADEXT WG consensus and therefore will require changes. &nbsp;<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>The major areas of concern include:<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>1. Treatment of complex attributes.&nbsp; &nbsp;These
concerns were raised in Issue 325 and relate to Section 2.1.3 and portions of
Appendix A. &nbsp;Proposals to move forward are included in the following
messages sent to the list: <o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.
http://ops.ietf.org/lists/radiusext/2010/msg00038.html<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.
http://ops.ietf.org/lists/radiusext/2010/msg00080.html<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c.
http://ops.ietf.org/lists/radiusext/2010/msg00107.html<o:p></o:p></p>

<p class=MsoNormal>2. &nbsp;Applicability.&nbsp; These concerns have been
raised in Issue 327, and relate to multiple sections in the document. &nbsp;Suggestions
on how to move forward have been made by Dan Romascanu in the following
message: &nbsp;http://ops.ietf.org/lists/radiusext/2010/msg00075.html<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>It is our hope that discussions on the mailing list will
result in proposed text addressing the concerns within the next week. &nbsp;<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>In order to provide a venue for additional discussion, we
will be posting a Doodle poll to determine times for a RADEXT Virtual Interim
meeting. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0050_01CA9FFF.AB27CE70--

Delivery-date: Wed, 27 Jan 2010 00:23:44 +0000
Cc: Dave Nelson <[email-masked]>, Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
From: "David B. Nelson" <[email-masked]>
To: Avi Lior <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Date: Tue, 26 Jan 2010 19:22:52 -0500

On Jan 26, 2010, at 5:52 PM, Avi Lior wrote:

>> The  NAS can ask questions of the form "I have this user, who has  
>> made a
>> connection attempt via that port / protocol, what access should I
>> provision to the user?"
>
> I am sorry i just dont see a difference.

I guess the difference is that the RADIUS server is free to ignore the  
contextual hints and simply provision the service that is dictated by  
the user's identity and context-independent policy.   The NAS need to  
be prepared to deal with *either* an Access-Accept provisioning an  
unexpected / unsupported service *or* an Access-Reject, in response to  
the same Access-Request.

Delivery-date: Tue, 26 Jan 2010 22:52:25 +0000
From: Avi Lior <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: Dave Nelson <[email-masked]>, Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 17:52:03 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

I fail to see a distinction here - but it could be me...

On 26-01-2010, at 23:21 , David B. Nelson wrote:

> It is a semantics issue.   The RADIUS model is to provision services  
> (authorize access) based on authenticated identity, contextual hints  
> from the NAS and server-based policy.  

Correct.  No problem here.

>  The NAS cannot ask questions  
> of the form "Would you allow this user to access that service?"  

This user = authenticated identity. (I have this user)
That service = contextual hints. (port/protocol)

> The  
> NAS can ask questions of the form "I have this user, who has made a  
> connection attempt via that port / protocol, what access should I  
> provision to the user?"

I am sorry i just dont see a difference.

Delivery-date: Tue, 26 Jan 2010 22:39:21 +0000
From: Avi Lior <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: Dave Nelson <[email-masked]>, Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 17:38:16 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

On 26-01-2010, at 23:15 , David B. Nelson wrote:

> On Jan 26, 2010, at 9:33 AM, Avi Lior wrote:
> 
>> -It would have been useful to allow VSA to be included in Access- 
>> Reject.
>> So at least an SDO can return an Error-Cause of their own or even
>> Authorization-Failure-Cause or Authentication-Failure-Cause instead of
>> hacking the Reply-Message attribute.
> 
> Potentially useful, yes, but also "dangerous".  If VSAs are allowed in  
> Access-Reject messages, it becomes much harder to maintain the "no  
> means no" doctrine.

If someone wanted to break the doctrine they can just hack Reply-Message or they can just use a VSA anyway.  You cant prevent anything if someone want to be dangerous or careless or whatever you want to call it.

If you want someone to be respectful of your protocol then you should create a protocol that demands respect by providing the tools necessary to meet the legitimate  usecases for which that protocol will be used.  Overtime those usecases will change.  Failing to recognize those changes means that people will fix it themselves and you wil loose control of the protocol.  This is exactly where we were heading before RADEXT was formed.  But the IETF was smart enough to recongize that the use of the RADIUS protocol is strong and is evolving.

So I would assert that telling a NAS why we are sending an Access-Reject is a valid use-case - after all Diameter allows the Server to specifically indicate when Authorization has failed (vs Authentication).

BTW I think what is also missing is how one translates between Diameter Result-Code and Error-Cause.

Delivery-date: Tue, 26 Jan 2010 15:21:42 +0000
Cc: Dave Nelson <[email-masked]>, Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
From: "David B. Nelson" <[email-masked]>
To: Avi Lior <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Date: Tue, 26 Jan 2010 10:21:08 -0500

On Jan 26, 2010, at 9:19 AM, Avi Lior wrote:

> "provisioning a service"  is authorization no?

Correct.

> I authenticate you then authorize you for a service by sending you  
> authorization attribute that define what service or services you  
> will receive.

Yes.

> I dont see a difference ... so i cant agree with:
>
>> After all, RADIUS is not about answering authorization questions  
>> from NASes,
>> it's about identifying users and *telling* them what service they  
>> get, based
>> on their identity, and contextual hints from the NAS.
>
> identifying users is authentication and telling them what service  
> they get is authorization.  Am I missing something?
>
> Anyway it may not be important that the language we are using is  
> aligned.

It is a semantics issue.   The RADIUS model is to provision services  
(authorize access) based on authenticated identity, contextual hints  
from the NAS and server-based policy.   The NAS cannot ask questions  
of the form "Would you allow this user to access that service?"  The  
NAS can ask questions of the form "I have this user, who has made a  
connection attempt via that port / protocol, what access should I  
provision to the user?"

Delivery-date: Tue, 26 Jan 2010 15:15:47 +0000
Cc: Dave Nelson <[email-masked]>, Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
From: "David B. Nelson" <[email-masked]>
To: Avi Lior <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Date: Tue, 26 Jan 2010 10:15:10 -0500

On Jan 26, 2010, at 9:33 AM, Avi Lior wrote:

> -It would have been useful to allow VSA to be included in Access- 
> Reject.
> So at least an SDO can return an Error-Cause of their own or even
> Authorization-Failure-Cause or Authentication-Failure-Cause instead of
> hacking the Reply-Message attribute.

Potentially useful, yes, but also "dangerous".  If VSAs are allowed in  
Access-Reject messages, it becomes much harder to maintain the "no  
means no" doctrine.

Delivery-date: Tue, 26 Jan 2010 14:34:16 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 09:33:35 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

The summary for this discussion is:

-Access-Accept should be used as defined by 5080.
-However there are dangers - which a capability negotiation could have solved.
-Error-Cause is for protocol errors mostly.  Having said that it does have a an Error Code 501 "Administratively Prohibited" which would be a stretch to call a protocol error.

Regarding the Errata. I still think it should be issued because it is not that obvious where Error-Cause can be included.  But we know.

-IANA should have clear instruction on how to extend Error-Cause.  Currently i dont think they do.

-Unless i am missing something, except for values 0-199 and 300-399, the RFCs do not reserve unused values for Error-Cause -- and then we wonder why people just grab numbers.

-It would have been useful to allow VSA to be included in Access-Reject. So at least an SDO can return an Error-Cause of their own or even Authorization-Failure-Cause or Authentication-Failure-Cause instead of hacking the Reply-Message attribute.

On 26-01-2010, at 21:51 , Dave Nelson wrote:

>> There are just too many unknowns around NAS behavior to over-load
>> Access-Accept.
> 
> I don't think anyone has suggested over-loading Access-Accept.  If use as
> originally intended, to provision service, it works just fine, at least if
> the service is described in the Service-Type attribute.
> 
> After all, RADIUS is not about answering authorization questions from NASes,
> it's about identifying users and *telling* them what service they get, based
> on their identity, and contextual hints from the NAS.
> 
> 

Delivery-date: Tue, 26 Jan 2010 14:20:43 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 09:19:59 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

Hmmmm

"provisioning a service"  is authorization no?

I authenticate you then authorize you for a service by sending you authorization attribute that define what service or services you will receive.

I dont see a difference ... so i cant agree with:

> After all, RADIUS is not about answering authorization questions from NASes,
> it's about identifying users and *telling* them what service they get, based
> on their identity, and contextual hints from the NAS.

identifying users is authentication and telling them what service they get is authorization.  Am I missing something?

Anyway it may not be important that the language we are using is aligned.

On 26-01-2010, at 21:51 , Dave Nelson wrote:

>> There are just too many unknowns around NAS behavior to over-load
>> Access-Accept.
> 
> I don't think anyone has suggested over-loading Access-Accept.  If use as
> originally intended, to provision service, it works just fine, at least if
> the service is described in the Service-Type attribute.
> 
> After all, RADIUS is not about answering authorization questions from NASes,
> it's about identifying users and *telling* them what service they get, based
> on their identity, and contextual hints from the NAS.
> 
> 

Delivery-date: Tue, 26 Jan 2010 13:51:50 +0000
From: "Dave Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Avi Lior'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC5176 (2012)
Date: Tue, 26 Jan 2010 08:51:48 -0500

> There are just too many unknowns around NAS behavior to over-load
> Access-Accept.

I don't think anyone has suggested over-loading Access-Accept.  If use as
originally intended, to provision service, it works just fine, at least if
the service is described in the Service-Type attribute.

After all, RADIUS is not about answering authorization questions from NASes,
it's about identifying users and *telling* them what service they get, based
on their identity, and contextual hints from the NAS.

Delivery-date: Tue, 26 Jan 2010 13:51:07 +0000
Date: Tue, 26 Jan 2010 14:50:54 +0100
From: Alan DeKok <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: 'Avi Lior' <[email-masked]>,  'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: [Technical Errata Reported] RFC5176 (2012)

Dave Nelson wrote:
> If the provisioning is via Service-Type, then NASes MUST treat provisioning
> of an unrecognized / unsupported service as if the message were an
> Access-Reject.  That's clearly stated and has been around long enough that
> any NAS failing to enforce this behavior is *badly* broken.

  Yes.

  It gets *much* worse than that.

  Alan DeKok.

Delivery-date: Tue, 26 Jan 2010 13:42:31 +0000
Date: Tue, 26 Jan 2010 14:42:00 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Dave Nelson <[email-masked]>,  Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Technical Errata Reported] RFC5176 (2012)

Avi Lior wrote:
> yes.  But the danger here is that the NAS may not understand the attributes that are offering the alternate (limiting) service and would interpret the response as a full access-accept.

  I agree.  Access-Accept means "let them on the network", and only
*partially* "give them limited services".  There are just too many
unknowns around NAS behavior to over-load Access-Accept.

> If the NAS did not indicate support for the new attributes that an Access-Reject may be the correct response.

  Many systems use Reply-Message as a feedback for failed
authentication.  e.g. "Password expired".

  I'm ambivalent about using Error-Cause.  I don't see many major
problem with it.  But it does extend the meaning of Access-Reject past
"go away, and I'm not telling you why".

  In this case, Error-Cause seems to be a substitute for an
administrator actually knowing the NAS capabilities, and configuring
them properly.  This would seem to be most useful for global proxy chains.

  Alan DeKok.

Delivery-date: Tue, 26 Jan 2010 13:42:29 +0000
From: "Dave Nelson" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC5176 (2012)
Date: Tue, 26 Jan 2010 08:42:18 -0500

> yes.  But the danger here is that the NAS may not understand the
> attributes that are offering the alternate (limiting) service and
> would interpret the response as a full access-accept.

If the provisioning is via Service-Type, then NASes MUST treat provisioning
of an unrecognized / unsupported service as if the message were an
Access-Reject.  That's clearly stated and has been around long enough that
any NAS failing to enforce this behavior is *badly* broken.

> For this situation to work correctly the sender of the Access-Accept
> would have to know whether or not the Receiver has to means to
> recognize the response correctly.

For subsidiary attributes that further modify the Service-Type attribute,
this is true. There are recommendations that NASes ought to have a local
policy regarding treatment of such attributes, but there is no absolute
guarantee.  Service-Type is the only RADIUS attribute that is implicitly
"mandatory" in all implementations.

> This could be provided by a capability exchange for example.

I always thought that would be useful and the WG never seemed to agree. 

Delivery-date: Tue, 26 Jan 2010 13:26:02 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 08:25:38 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

i agree with you David,  see inline...

On 26-01-2010, at 21:11 , Dave Nelson wrote:

>> So it is 5580 that actually uses it in Access-Reject.
> 
> That usage is as follows:
> 
>   o  If the RADIUS server does not receive the requested information in
>      response to the Access-Challenge (including the Requested-
>      Location-Info Attribute), then the RADIUS server may respond with
>      an Access-Reject message with an Error-Cause Attribute (including
>      the "Location-Info-Required" value).
> 
> It constitutes a "poor-man's" form of capabilities negotiations, in that it
> signals that needed information that is missing from an
> Authentication-Request.  It is not use to signal a limited or alternate form
> of service to be provided as a result of the Access-Reject, however.  That
> would violate the "no means no" doctrine.

Understood.

> 
>> Given the above the situation is very grim.  Error-Cause is not the right
>> attribute.
> 
> I think it is not the right attribute.  In fact I think there is no
> attribute that *can* be use to change an Access-Reject into a modified,
> limited or alternate form of Access-Accept.
Right.
> 
>> In a situation where the AAA Server doesnt not intend to allow for access
>> to the service provided - an access-accept is should not be used.  Access-
>> Reject does not allow us to use even a Vendor Specific Attribute (26) so
>> we cant communicate the reason for rejection.
> 
> Correct.
> 
>> The only solution is to use Access-Accept with a code that indicates that
>> no service should be provided.  This is a terrible solution/situation.
> 
> Well, if *no* service is to be provided, then why isn't an Access-Reject
> appropriate?  

When I meant no service - it is not the service that was requested.

> OTOH, if what's really happening is that the RADIUS server is
> provisioning an alternate form of service, maybe even one that the NAS is
> not in a position to provide, why not send an Access-Accept including a set
> of attributes that provision the allowed service and let the NAS decide if
> it can provide that service, and if not how it wants to signal to the client
> that the alternate (allowed) service is not achievable on that connection?

yes.  But the danger here is that the NAS may not understand the attributes that are offering the alternate (limiting) service and would interpret the response as a full access-accept.

For this situation to work correctly the sender of the Access-Accept would have to know whether or not the Receiver has to means to recognize the response correctly.  This could be provided by a capability exchange for example.

If the NAS did not indicate support for the new attributes that an Access-Reject may be the correct response.

Delivery-date: Tue, 26 Jan 2010 13:19:56 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 08:19:30 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

Yes 5080 is helpful here - I remember this discussion.  I can use it to clear up the issue and squash any arguments at the SDO.

It both describes a problem and provides a way to address this problem:

"If the desire is to allow
   limited access, then an Access-Accept can be sent with attributes
   provisioning limited access. "

I wish another document was as clear ;-)

There are still issues with this approach since a legacy NAS may not recognize the attributes that provision the limited access.  It would have been good to include the warning.

However, in my case this is not going to be a problem.

On 26-01-2010, at 20:58 , Dave Nelson wrote:

>> As you say, most of the existing uses of Error-Cause are for
>> protocol error of some kind, so in looking at the IEEE 802.1X-REV 
>> authorization scenarios, the preliminary thinking was to use some
>> other attribute to communicate the content that might end up in
>> EAPOL-Announcements that provide the client with an indication
>> of the access status.
> 
> Haven't we already clarified, in RFC 5080 Section 2.6, that with the use of
> an Access-Reject message "no means no" and that Access-Reject cannot be used
> to provision restricted or alternate forms of service or access?
> 
> 

Delivery-date: Tue, 26 Jan 2010 13:12:00 +0000
From: "Dave Nelson" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC5176 (2012)
Date: Tue, 26 Jan 2010 08:11:40 -0500

> So it is 5580 that actually uses it in Access-Reject.

That usage is as follows:

   o  If the RADIUS server does not receive the requested information in
      response to the Access-Challenge (including the Requested-
      Location-Info Attribute), then the RADIUS server may respond with
      an Access-Reject message with an Error-Cause Attribute (including
      the "Location-Info-Required" value).

It constitutes a "poor-man's" form of capabilities negotiations, in that it
signals that needed information that is missing from an
Authentication-Request.  It is not use to signal a limited or alternate form
of service to be provided as a result of the Access-Reject, however.  That
would violate the "no means no" doctrine.

> Given the above the situation is very grim.  Error-Cause is not the right
> attribute.

I think it is not the right attribute.  In fact I think there is no
attribute that *can* be use to change an Access-Reject into a modified,
limited or alternate form of Access-Accept.

> In a situation where the AAA Server doesnt not intend to allow for access
> to the service provided - an access-accept is should not be used.  Access-
> Reject does not allow us to use even a Vendor Specific Attribute (26) so
> we cant communicate the reason for rejection.

Correct.

> The only solution is to use Access-Accept with a code that indicates that
> no service should be provided.  This is a terrible solution/situation.

Well, if *no* service is to be provided, then why isn't an Access-Reject
appropriate?  OTOH, if what's really happening is that the RADIUS server is
provisioning an alternate form of service, maybe even one that the NAS is
not in a position to provide, why not send an Access-Accept including a set
of attributes that provision the allowed service and let the NAS decide if
it can provide that service, and if not how it wants to signal to the client
that the alternate (allowed) service is not achievable on that connection?

Delivery-date: Tue, 26 Jan 2010 12:59:20 +0000
From: "Dave Nelson" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'Avi Lior'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC5176 (2012)
Date: Tue, 26 Jan 2010 07:58:38 -0500
> As you say, most of the existing uses of Error-Cause are for
> protocol error of some kind, so in looking at the IEEE 802.1X-REV 
> authorization scenarios, the preliminary thinking was to use some
> other attribute to communicate the content that might end up in
> EAPOL-Announcements that provide the client with an indication
> of the access status.

Haven't we already clarified, in RFC 5080 Section 2.6, that with the use of
an Access-Reject message "no means no" and that Access-Reject cannot be used
to provision restricted or alternate forms of service or access?

Delivery-date: Tue, 26 Jan 2010 07:15:58 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 02:15:10 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

On 26-01-2010, at 14:06 , Bernard Aboba wrote:

> A quick search turned up the following references to Error-Cause in RADIUS
> RFCs:
> 
> RFC 3579 explicitly enables inclusion of Error-Cause in Access-Reject and
> Access-Challenge messages (see Section 3.3). 
> RFC 3580 lists Error-Cause in Table 8. 
> RFC 4672 mentions Error-Cause in definition of MIB objects.
> RFC 5176 talks about use in CoA and Disconnect messages. 
> RFC 5580 uses Error-Cause (e.g. for "Location-Info-Required"). 
> 
> It's possible I've missed a few references/uses.  But on this basis alone,
> there shouldn't be much question that it
> can be used beyond CoA and Disconnect messages -- especially since RFC 5176
> doesn't update RFC 3579 (so that anything said in RFC 3579 isn't affected). 
The problem is still that the use of Error-Cause in Access-Reject is not that obvious.  3579 talks about using it in Access-Challenge and only in the table of attributes does it show it as 0-1 in Reject.

3580 is totally vague about Error-Cause.

4672 only counts when Error-Cause is in Coa-NAK or Disconnect-NAK.  So it does not provide any hints about Error-Cause in any Access-Reject.

So it is 5580 that actually uses it in Access-Reject.

So the reader would have to specifically read the table of occurance in 3579 or 5580 to know that they can use this attribute in Access-Reject.

The proposed errata would be helpful - but I will let you guys decide.

> 
> The issue of authorization has come up in a number of situations, most
> recently IEEE 802.1X-REV, where within an Access-Accept, a user can be
> authorized for a variety of levels of access, from unfettered access to
> restricted access.  There are also situations where the client might not
> implement IEEE 802.1X at all, but where it is still desired to allow the
> client on the network in some form (perhaps via a Web portal or restricted
> access of some kind), so that RADIUS might still end up being used,
> conceivably.  
> 
> As you say, most of the existing uses of Error-Cause are for protocol error
> of some kind, so in looking at the IEEE 802.1X-REV authorization scenarios,
> the preliminary thinking was to use some other attribute to communicate the
> content that might end up in EAPOL-Announcements that provide the client
> with an indication of the access status. 

Given the above the situation is very grim.  Error-Cause is not the right attribute.

In a situation where the AAA Server doesnt not intend to allow for access to the service provided - an access-accept is should not be used.  Access-Reject does not allow us to use even a Vendor Specific Attribute (26) so we cant communicate the reason for rejection.

The only solution is to use Access-Accept with a code that indicates that no service should be provided.  This is a terrible solution/situation.

> 
> 
> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]] 
> Sent: Monday, January 25, 2010 9:15 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [Technical Errata Reported] RFC5176 (2012)
> 
> Yes.  There is confusion between reading 2865 and various other RFC.
> 
> The only RFC that I found that allows Error-Cause to be included in other
> messages was 3579.  Is there another?
> 
> In fact I am faced with this problem as we speak.  Let me try to explain the
> various issues:
> 
> We  need a mechanism to indicate why an authentication/authorization has
> failed. 
> 
> First there are scenarios where the authentication has failed.  For that
> access-reject seems to suffice.
> 
> But we also have scenario where authentication has succeeded but
> authorization has failed.
> In this case we need to communicate to the NAS why the session was not
> authorized.  This is needed so the NAS can make an intelligent decision or
> take alternative action.
> 
> The case in point is Femtocell authentication/authorization.
> 
> If the mobile is not authenticated then Access-Reject is the appropriate
> answer since no service is to be provided.
> 
> If the mobile is authenticated and not authorized for femto use then the
> Femtocell needs to interact with the mobile to get it to use the Macro cell
> (for example).
> 
> How do we tell the Femtocell that the MS is not authorized.
> 
> Access-Accept with an attribute indicating  that the MS is not authorized is
> workable but may be a problem.  A legacy  Femtocell that is not aware of the
> attribute will ignore the attribute and interpret the access-accept as
> permission to offer service.
> 
> An access-reject is a better option but we need to be able to carry
> additional information -- currently we dont have too many options.  Reply
> message which is not really intended for the Femtocell.  Error-Cause would
> work but we would need it to be extended by SDOs.
> 
> Note that Error-Cause may also be the wrong attribute to use.  One would
> (correctly) argue that its purpose is to only indicate when errors have
> occurred in the protocol.  Failure to authorize is not an error condition of
> the protocol.
> 
> 
> Avi. 
> 
> 
> On 26-01-2010, at 12:05 , Bernard Aboba wrote:
> 
>> The intent in writing that sentence was just to clarify use of Error-Cause
>> in CoA and Disconnect messages (the topic of RFC 5176).   So the intent
> was
>> not to update RFC 3579, or somehow imply that previous usages were
>> deprecated.  As you say, Error-Cause can be included in other messages as
>> well. 
>> 
>> Has there been confusion on this issue in the field?
>> 
>> -----Original Message-----
>> From: RFC Errata System [mailto:[email-masked]] 
>> Sent: Monday, January 25, 2010 7:43 PM
>> To: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked];
>> [email-masked]
>> Subject: [Technical Errata Reported] RFC5176 (2012)
>> 
>> 
>> The following errata report has been submitted for RFC5176, "Dynamic
>> Authorization Extensions to Remote Authentication Dial In User Service
>> (RADIUS)".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=2012
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Avi Lior <[email-masked]>
>> 
>> Section: 3.5
>> 
>> Original Text
>> -------------
>> Values 200-299 represent successful completion, so that thesevalues may
> only
>> be sent within CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent
> within
>> a CoA-NAK or Disconnect-NAK packet.
>> 
>> Corrected Text
>> --------------
>> Values 200-299 represent successful completion, so that thesevalues may be
>> sent in other reply messages such as Access-Reject, Access-Challenge,
>> CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within a CoA-NAK or
>> Disconnect-NAK packet.
>> 
>> Notes
>> -----
>> RFC 3579  allows for Error-Cause to be sent (specifically) in an
>> access-challenge and also in Reject messages as well.The specification in
>> 5176 restricts the usage and should be clarified especially since 5176 was
>> published after 3579.I proposed minimal text but I think a broader
> approach
>> is needed for this attribute.  Here are some thoughts:1) Error-Cause is
>> needed in Access-Reject (as is allowed by 3579)2) IANA should have
>> procedures for defining new values (currently no procedure is defined).
> SDO
>> need to be able to use Error-Cause to report back why an
>> Authentication/Authorization failed.  Error-Cause seems to be the only
>> solution other than Reply-Message which is not really designed for
> reporting
>> error cause to the NAS.
>> 
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please use
>> "Reply All" to discuss whether it should be verified or rejected. When a
>> decision is reached, the verifying party (IESG) can log in to change the
>> status and edit the report, if necessary. 
>> 
>> --------------------------------------
>> RFC5176 (draft-ietf-radext-rfc3576bis-13)
>> --------------------------------------
>> Title               : Dynamic Authorization Extensions to Remote
>> Authentication Dial In User Service (RADIUS)
>> Publication Date    : January 2008
>> Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba
>> Category            : INFORMATIONAL
>> Source              : RADIUS EXTensions
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
>> 
> 
> 

Delivery-date: Tue, 26 Jan 2010 06:05:54 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>
CC: <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC5176 (2012)
Date: Mon, 25 Jan 2010 22:06:36 -0800

A quick search turned up the following references to Error-Cause in RADIUS
RFCs:

RFC 3579 explicitly enables inclusion of Error-Cause in Access-Reject and
Access-Challenge messages (see Section 3.3). 
RFC 3580 lists Error-Cause in Table 8. 
RFC 4672 mentions Error-Cause in definition of MIB objects.
RFC 5176 talks about use in CoA and Disconnect messages. 
RFC 5580 uses Error-Cause (e.g. for "Location-Info-Required"). 

It's possible I've missed a few references/uses.  But on this basis alone,
there shouldn't be much question that it
can be used beyond CoA and Disconnect messages -- especially since RFC 5176
doesn't update RFC 3579 (so that anything said in RFC 3579 isn't affected). 

The issue of authorization has come up in a number of situations, most
recently IEEE 802.1X-REV, where within an Access-Accept, a user can be
authorized for a variety of levels of access, from unfettered access to
restricted access.  There are also situations where the client might not
implement IEEE 802.1X at all, but where it is still desired to allow the
client on the network in some form (perhaps via a Web portal or restricted
access of some kind), so that RADIUS might still end up being used,
conceivably.  

As you say, most of the existing uses of Error-Cause are for protocol error
of some kind, so in looking at the IEEE 802.1X-REV authorization scenarios,
the preliminary thinking was to use some other attribute to communicate the
content that might end up in EAPOL-Announcements that provide the client
with an indication of the access status. 

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Monday, January 25, 2010 9:15 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [Technical Errata Reported] RFC5176 (2012)

Yes.  There is confusion between reading 2865 and various other RFC.

The only RFC that I found that allows Error-Cause to be included in other
messages was 3579.  Is there another?

In fact I am faced with this problem as we speak.  Let me try to explain the
various issues:

We  need a mechanism to indicate why an authentication/authorization has
failed. 

First there are scenarios where the authentication has failed.  For that
access-reject seems to suffice.

But we also have scenario where authentication has succeeded but
authorization has failed.
In this case we need to communicate to the NAS why the session was not
authorized.  This is needed so the NAS can make an intelligent decision or
take alternative action.

The case in point is Femtocell authentication/authorization.

If the mobile is not authenticated then Access-Reject is the appropriate
answer since no service is to be provided.

If the mobile is authenticated and not authorized for femto use then the
Femtocell needs to interact with the mobile to get it to use the Macro cell
(for example).

How do we tell the Femtocell that the MS is not authorized.

Access-Accept with an attribute indicating  that the MS is not authorized is
workable but may be a problem.  A legacy  Femtocell that is not aware of the
attribute will ignore the attribute and interpret the access-accept as
permission to offer service.

An access-reject is a better option but we need to be able to carry
additional information -- currently we dont have too many options.  Reply
message which is not really intended for the Femtocell.  Error-Cause would
work but we would need it to be extended by SDOs.

Note that Error-Cause may also be the wrong attribute to use.  One would
(correctly) argue that its purpose is to only indicate when errors have
occurred in the protocol.  Failure to authorize is not an error condition of
the protocol.

Avi. 

On 26-01-2010, at 12:05 , Bernard Aboba wrote:

> The intent in writing that sentence was just to clarify use of Error-Cause
> in CoA and Disconnect messages (the topic of RFC 5176).   So the intent
was
> not to update RFC 3579, or somehow imply that previous usages were
> deprecated.  As you say, Error-Cause can be included in other messages as
> well. 
> 
> Has there been confusion on this issue in the field?
> 
> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]] 
> Sent: Monday, January 25, 2010 7:43 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Technical Errata Reported] RFC5176 (2012)
> 
> 
> The following errata report has been submitted for RFC5176, "Dynamic
> Authorization Extensions to Remote Authentication Dial In User Service
> (RADIUS)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfcQ76&eid 12
> 
> --------------------------------------
> Type: Technical
> Reported by: Avi Lior <[email-masked]>
> 
> Section: 3.5
> 
> Original Text
> -------------
> Values 200-299 represent successful completion, so that thesevalues may
only
> be sent within CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent
within
> a CoA-NAK or Disconnect-NAK packet.
> 
> Corrected Text
> --------------
> Values 200-299 represent successful completion, so that thesevalues may be
> sent in other reply messages such as Access-Reject, Access-Challenge,
> CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within a CoA-NAK or
> Disconnect-NAK packet.
> 
> Notes
> -----
> RFC 3579  allows for Error-Cause to be sent (specifically) in an
> access-challenge and also in Reject messages as well.The specification in
> 5176 restricts the usage and should be clarified especially since 5176 was
> published after 3579.I proposed minimal text but I think a broader
approach
> is needed for this attribute.  Here are some thoughts:1) Error-Cause is
> needed in Access-Reject (as is allowed by 3579)2) IANA should have
> procedures for defining new values (currently no procedure is defined).
SDO
> need to be able to use Error-Cause to report back why an
> Authentication/Authorization failed.  Error-Cause seems to be the only
> solution other than Reply-Message which is not really designed for
reporting
> error cause to the NAS.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party (IESG) can log in to change the
> status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5176 (draft-ietf-radext-rfc3576bis-13)
> --------------------------------------
> Title               : Dynamic Authorization Extensions to Remote
> Authentication Dial In User Service (RADIUS)
> Publication Date    : January 2008
> Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba
> Category            : INFORMATIONAL
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 

Delivery-date: Tue, 26 Jan 2010 05:16:01 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 26 Jan 2010 00:15:09 -0500
Subject: Re: [Technical Errata Reported] RFC5176 (2012)
Accept-Language: en-US
acceptlanguage: en-US

Yes.  There is confusion between reading 2865 and various other RFC.

The only RFC that I found that allows Error-Cause to be included in other messages was 3579.  Is there another?

In fact I am faced with this problem as we speak.  Let me try to explain the various issues:

We  need a mechanism to indicate why an authentication/authorization has failed. 

First there are scenarios where the authentication has failed.  For that access-reject seems to suffice.

But we also have scenario where authentication has succeeded but authorization has failed.
In this case we need to communicate to the NAS why the session was not authorized.  This is needed so the NAS can make an intelligent decision or take alternative action.

The case in point is Femtocell authentication/authorization.

If the mobile is not authenticated then Access-Reject is the appropriate answer since no service is to be provided.

If the mobile is authenticated and not authorized for femto use then the Femtocell needs to interact with the mobile to get it to use the Macro cell (for example).

How do we tell the Femtocell that the MS is not authorized.

Access-Accept with an attribute indicating  that the MS is not authorized is workable but may be a problem.  A legacy  Femtocell that is not aware of the attribute will ignore the attribute and interpret the access-accept as permission to offer service.

An access-reject is a better option but we need to be able to carry additional information -- currently we dont have too many options.  Reply message which is not really intended for the Femtocell.  Error-Cause would work but we would need it to be extended by SDOs.

Note that Error-Cause may also be the wrong attribute to use.  One would (correctly) argue that its purpose is to only indicate when errors have occurred in the protocol.  Failure to authorize is not an error condition of the protocol.

Avi. 

On 26-01-2010, at 12:05 , Bernard Aboba wrote:

> The intent in writing that sentence was just to clarify use of Error-Cause
> in CoA and Disconnect messages (the topic of RFC 5176).   So the intent was
> not to update RFC 3579, or somehow imply that previous usages were
> deprecated.  As you say, Error-Cause can be included in other messages as
> well. 
> 
> Has there been confusion on this issue in the field?
> 
> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]] 
> Sent: Monday, January 25, 2010 7:43 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Technical Errata Reported] RFC5176 (2012)
> 
> 
> The following errata report has been submitted for RFC5176, "Dynamic
> Authorization Extensions to Remote Authentication Dial In User Service
> (RADIUS)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=2012
> 
> --------------------------------------
> Type: Technical
> Reported by: Avi Lior <[email-masked]>
> 
> Section: 3.5
> 
> Original Text
> -------------
> Values 200-299 represent successful completion, so that thesevalues may only
> be sent within CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within
> a CoA-NAK or Disconnect-NAK packet.
> 
> Corrected Text
> --------------
> Values 200-299 represent successful completion, so that thesevalues may be
> sent in other reply messages such as Access-Reject, Access-Challenge,
> CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within a CoA-NAK or
> Disconnect-NAK packet.
> 
> Notes
> -----
> RFC 3579  allows for Error-Cause to be sent (specifically) in an
> access-challenge and also in Reject messages as well.The specification in
> 5176 restricts the usage and should be clarified especially since 5176 was
> published after 3579.I proposed minimal text but I think a broader approach
> is needed for this attribute.  Here are some thoughts:1) Error-Cause is
> needed in Access-Reject (as is allowed by 3579)2) IANA should have
> procedures for defining new values (currently no procedure is defined). SDO
> need to be able to use Error-Cause to report back why an
> Authentication/Authorization failed.  Error-Cause seems to be the only
> solution other than Reply-Message which is not really designed for reporting
> error cause to the NAS.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party (IESG) can log in to change the
> status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5176 (draft-ietf-radext-rfc3576bis-13)
> --------------------------------------
> Title               : Dynamic Authorization Extensions to Remote
> Authentication Dial In User Service (RADIUS)
> Publication Date    : January 2008
> Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba
> Category            : INFORMATIONAL
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 

Delivery-date: Tue, 26 Jan 2010 04:06:44 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC5176 (2012)
Date: Mon, 25 Jan 2010 20:05:45 -0800

The intent in writing that sentence was just to clarify use of Error-Cause
in CoA and Disconnect messages (the topic of RFC 5176).   So the intent was
not to update RFC 3579, or somehow imply that previous usages were
deprecated.  As you say, Error-Cause can be included in other messages as
well. 

Has there been confusion on this issue in the field?

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]] 
Sent: Monday, January 25, 2010 7:43 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [Technical Errata Reported] RFC5176 (2012)

The following errata report has been submitted for RFC5176, "Dynamic
Authorization Extensions to Remote Authentication Dial In User Service
(RADIUS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfcQ76&eid 12

--------------------------------------
Type: Technical
Reported by: Avi Lior <[email-masked]>

Section: 3.5

Original Text
-------------
Values 200-299 represent successful completion, so that thesevalues may only
be sent within CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within
a CoA-NAK or Disconnect-NAK packet.

Corrected Text
--------------
Values 200-299 represent successful completion, so that thesevalues may be
sent in other reply messages such as Access-Reject, Access-Challenge,
CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within a CoA-NAK or
Disconnect-NAK packet.

Notes
-----
RFC 3579  allows for Error-Cause to be sent (specifically) in an
access-challenge and also in Reject messages as well.The specification in
5176 restricts the usage and should be clarified especially since 5176 was
published after 3579.I proposed minimal text but I think a broader approach
is needed for this attribute.  Here are some thoughts:1) Error-Cause is
needed in Access-Reject (as is allowed by 3579)2) IANA should have
procedures for defining new values (currently no procedure is defined). SDO
need to be able to use Error-Cause to report back why an
Authentication/Authorization failed.  Error-Cause seems to be the only
solution other than Reply-Message which is not really designed for reporting
error cause to the NAS.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary. 

--------------------------------------
RFC5176 (draft-ietf-radext-rfc3576bis-13)
--------------------------------------
Title               : Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)
Publication Date    : January 2008
Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba
Category            : INFORMATIONAL
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

Delivery-date: Sun, 24 Jan 2010 13:44:18 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Romascanu, Dan (Dan)" <[email-masked]>, David Nelson <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 24 Jan 2010 08:43:56 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

Thank you -- I will provide a review.
On 24-01-2010, at 17:09 , Alan DeKok wrote:

> Romascanu, Dan (Dan) wrote:
>> I am also reminding the proposal that I have made a week ago. Can you
>> get together (maybe the two of you - Alan and Avi) and create text to be
>> added to the current document about what this BCP covers, and what it
>> does not cover and may be in the scope of future work?
> 
>  Proposed text is available:
> 
> http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt
> 
>  It doesn't address of all Avi's suggestions, but it covers most.
> 
>  I'd like to see a review, and suggestions for what else needs addressing.
> 
>  Alan DeKok.

Delivery-date: Sun, 24 Jan 2010 13:42:27 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Sun, 24 Jan 2010 08:41:31 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

I dont disagree with most of what you are saying...but I want to focus back to the point...

In an exchange on Jan 18 David Nelson wrote...

"This may be true of a class of newer RADIUS server implementations, those
with a "dynamic" data dictionary, but it is not true of another class of
more "traditional" RADIUS servers, and it's those that this section intends
to address."

The document should clearly state what you wrote...otherwise, it will create confusion - as you can see...

Or improve the text to encompass all different types of models/deployments/implementations ... I don't think you want to do that.

But what is clearly not acceptable is to leave the document as is.

On 22-01-2010, at 21:50 , Dave Nelson wrote:

> Avi Lior writes...
> 
>> I would think that the BCP that would be published today
>> will be reflecting the new RADIUS designs but if that is not
>> the case then we need to be clear about the applicability of
>> this document.  I am okay with a BCP that applies to protecting
>> traditional RADIUS usage but we need to be clear about it.
>> 
>> Can we start with this then...
> 
> I'm not sure what this really means.  I *suspect* that it provides a
> convenient way to dismiss the document as being irrelevant when doing new
> RADIUS work in "walled gardens" of "current technology" RADIUS server
> deployments.
> 
> The thing about protocols is that they are simply words on paper.  A
> *protocol* can not be said to have the property of multi-vendor
> interoperability.  Only *implementations* of protocols can be tested to see
> if interoperability is obtained.  Given that multi-vendor interoperability
> is a key concern of IETF Standards-Track protocols, we can't dispense with
> discussing implementations.
> 
> If a sufficient number of implementations take advantage of any given
> property of a protocol, such the simplicity of that protocol's data model,
> that property, e.g. the data model, becomes an integral element of the
> protocol.
> 
> That's the case here.  The simple data model is an inherent property of the
> RADIUS protocol by virtue of many implementations having relied upon it, if
> for no other reason.  If we want to expand the data model, to be more rich
> and complex, we therefore need to either revise or extend the protocol.
> 
> IMO, We can't simply say that the past is irrelevant, and we're going to
> define a new version of the protocol that works well with a class of newly
> designed implementations.  That would violate the basic tenets of
> multi-vendor interoperability.
> 
> I'm all *for* expanding the RADIUS data model.  In fact, my personal
> preferences in that regard extend beyond what the WG has achieved consensus
> to support.  However, we need to do that within the constraints of a
> reasonable protocol evolution methodology.  Either we add a protocol version
> number negotiation methodology or we use an "escape" mechanism such as the
> Extended Attribute format.
> 
> I think that simply ignoring the interoperability considerations of a
> significant class of implementations, by labeling them "traditional",
> legacy" or "historic" (or any other synonym) is the wrong thing to do.
> 
> 
> 
> --

Delivery-date: Sun, 24 Jan 2010 09:10:48 +0000
Date: Sun, 24 Jan 2010 10:09:55 +0100
From: Alan DeKok <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: Avi Lior <[email-masked]>,  David Nelson <[email-masked]>, Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Romascanu, Dan (Dan) wrote:
> I am also reminding the proposal that I have made a week ago. Can you
> get together (maybe the two of you - Alan and Avi) and create text to be
> added to the current document about what this BCP covers, and what it
> does not cover and may be in the scope of future work?

  Proposed text is available:

http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

  It doesn't address of all Avi's suggestions, but it covers most.

  I'd like to see a review, and suggestions for what else needs addressing.

  Alan DeKok.

Delivery-date: Sun, 24 Jan 2010 07:51:10 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Sun, 24 Jan 2010 08:49:22 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Alan DeKok" <[email-masked]>, "David Nelson" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, "Glen Zorn" <[email-masked]>

The AD is unhappy with all discussions that are inefficient and
sometimes are taking personal tones. 

I am making again an appeal to all the participants in the discussion to
focus on the professional aspects of the debate and to abstain from
remarks that can be interpreted as personal. 

I am also reminding the proposal that I have made a week ago. Can you
get together (maybe the two of you - Alan and Avi) and create text to be
added to the current document about what this BCP covers, and what it
does not cover and may be in the scope of future work? Get WG consensus
on this text, have this BCP approved, and recharter the Working Group to
work on what is not covered by the BCP like adding complex types. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]] 
> Sent: Saturday, January 23, 2010 12:53 AM
> To: Alan DeKok; David Nelson; Bernard Aboba; Romascanu, Dan (Dan)
> Cc: [email-masked]; Glen Zorn
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> The tone of your responses is what I find offensive....
> 
> No Alan, the purpose of all my post it to get the document to 
> be the best possible document.  One would start wondering 
> what is the purpose of your posts...is it to protect your 
> implementation, you beloved FreeRadius...hmmmmm I think it is.
> 
> We have seen this type of shameless self promoting from you 
> before: one just needs to look at the section 2.1.2 of 
> RFC5080 with its shameless taunting of what a wonderful job 
> FreeRadius did.  NOT really actually ... a pretty obvious 
> non-novel solution.  Such text has no place in an RFC. 
> 
> I am trying to keep this professional and not personal. You 
> persist with personal, patronizing attacks on me and my 
> comments...but if you want to continue down the lines of 
> personal attacks and the chairs and AD are obviously happy 
> with this...then I have better things to do.
> 
> If I were the only one that is raising these issues I would 
> just walk away.  But I am NOT the only one.  So stop the 
> personal attacks on my criticism of this body of work.
> 
> And to Bernard, and David act like chairs.
> 
> And to Dan, Bernard, David and Alan....I take you to the BAD 
> email discussion with Glen. This is a caustic WG...Great job guys.
> 
> 
> On 22-01-2010, at 15:29 , Alan DeKok wrote:
> 
> > Avi Lior wrote:
> >> Can we start with this then...
> > 
> >  I see your false dichotomy and raise you one:
> > 
> >  Is the purpose of your post to be intentionally offensive, 
> or did you 
> > simply not see the dozens of posts explaining the document?
> > 
> >  Alan DeKok.
> 
> 

Delivery-date: Sat, 23 Jan 2010 08:01:16 +0000
Date: Sat, 23 Jan 2010 09:00:18 +0100
From: Alan DeKok <[email-masked]>
To: Ignacio Goyret <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: FW: Review of draft-ietf-radext-status-server

Ignacio Goyret wrote:
> IMO, the use of Access-Accept for a use
> *other* than what it has always been intended for is opening
> a can of worms with potentially unintended consequences.

  I agree with that.  If the document had been a WG item, Status-Server
packets would have had a Status-Response packet.

> However, in the Security section, it should be mentioned that
> both servers and clients can be attacked independently when
> either one supports Server-Status, even if the other doesn't.

  OK.

  Alan DeKok.

Delivery-date: Sat, 23 Jan 2010 00:53:11 +0000
Date: Fri, 22 Jan 2010 16:51:19 -0800
To: Alan DeKok <[email-masked]>
From: Ignacio Goyret <[email-masked]>
Subject: Re: FW: Review of draft-ietf-radext-status-server
Cc: Ignacio Goyret <[email-masked]>, Bernard Aboba <[email-masked]>, [email-masked]

At 01:22 AM 1/23/2010 +0100, Alan DeKok wrote:
>Ignacio Goyret wrote:
>> A client has *no* reliable way to find out if an incoming
>> Access-Accept is for an Access-Request it sent or from an
>> Status-Server sent by an attacker (with a possibly problematic
>> server).
>
>  But this attack is possible in RADIUS without Status-Server.

Exactly. So, why are we trying to add yet another attack vector?

>> See why this is a slippery slope?
>
>  Oh, yes.  But the problem is mostly due to un-authenticated request
>packets, and less so to the use of Access-Accept.

Let's agree to disagree. IMO, the use of Access-Accept for a use
*other* than what it has always been intended for is opening
a can of worms with potentially unintended consequences.

A clean, simple design would call for specialized codes,
specially considering that there is plenty of unused code
points.

However, in the Security section, it should be mentioned that
both servers and clients can be attacked independently when
either one supports Server-Status, even if the other doesn't.

>> IMHO, people should be advised to NOT use this method of
>> checking the servers.
>
>  Hmm... even though this attack is already possible in RADIUS?

Yes, because it adds a new and different attack vector.

>  The only defense is to require that Access-Request (and Status-Server)
>packets be signed.

I disagree.

A much better defense (without altering the basic RADIUS paradigm)
would be to use another code for a response, one that cannot be
confused with any possible authentication.

Since the purpose of the Status-Server is to check whether
the server is ok, then the response should be such that 
cannot ever be confused *ever* with anything else.

Barring a solution where the server response cannot be confused,
my opinion against using this method stands.

>  We can also presume that the RADIUS client && server will be
>configured by people who communicate.  i.e. the "client" is also
>partially the admin, who knows that the server supports signed
>Status-Server, and therefore can safely enable it on the client.

Think of the case where one of the two parts has to support it
because *part* of your network supports it (say some clients
or some servers), just not all of it. The choice of using an
Access-Accept response opens new doors for attacks.

It would be enough that *part* of the network can't or doesn't
know how to deal with these new sets of Access-Accept and
the admin has a serious problem. Furthermore, in many cases,
servers or clients are usually not under the same admin SOC
which makes the mixed environment very likely.

But, like I mentioned in earlier emails, this is all academic
and it doesn't really matter much because this is just an
informational RFC. It would be a very different story if
it was intended for standards track.

Take care,
-Ignacio

Delivery-date: Sat, 23 Jan 2010 00:22:37 +0000
Date: Sat, 23 Jan 2010 01:22:14 +0100
From: Alan DeKok <[email-masked]>
To: Ignacio Goyret <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: FW: Review of draft-ietf-radext-status-server

Ignacio Goyret wrote:
> A client has *no* reliable way to find out if an incoming
> Access-Accept is for an Access-Request it sent or from an
> Status-Server sent by an attacker (with a possibly problematic
> server).

  But this attack is possible in RADIUS without Status-Server.

  We can presume that the attacker possesses at least one "known good"
user password.  (i.e. via signing up for a temporary account).  Then
this attack can be performed at will: sniff an Access-Request, and
quickly replace it with a "fake" one containing the same Id && Request
authenticator, but with the "fake" CHAP-Password and CHAP-Challenge.

  The server will respond with Access-Accept, and authorize the other
session.

> See why this is a slippery slope?

  Oh, yes.  But the problem is mostly due to un-authenticated request
packets, and less so to the use of Access-Accept.

> IMHO, people should be advised to NOT use this method of
> checking the servers.

  Hmm... even though this attack is already possible in RADIUS?

  The only defense is to require that Access-Request (and Status-Server)
packets be signed.  RFC 5080 Section 2.2.2 makes this recommendation for
Access-Requests.  This document makes the same recommendation for
Status-Server.

  We can also presume that the RADIUS client && server will be
configured by people who communicate.  i.e. the "client" is also
partially the admin, who knows that the server supports signed
Status-Server, and therefore can safely enable it on the client.

  Alan DeKok.

Delivery-date: Fri, 22 Jan 2010 23:54:58 +0000
Date: Sat, 23 Jan 2010 00:54:26 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: David Nelson <[email-masked]>,  Bernard Aboba <[email-masked]>, "Dan (Dan) Romascanu" <[email-masked]>,  "[email-masked]" <[email-masked]>, Glen Zorn <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> The tone of your responses is what I find offensive....

  Describing competing products as "legacy" wasn't meant as a put-down,
of course.  Describing people as "shameless" wasn't negative, either.

> No Alan, the purpose of all my post it to get the document to be the best possible document.  One would start wondering what is the purpose of your posts...is it to protect your implementation, you beloved FreeRadius...hmmmmm I think it is.

  You mean that I'm the first vendor in the history of the IETF who is
trying to influence the standards process?  I'm glad I made history.

> If I were the only one that is raising these issues I would just walk away.  But I am NOT the only one.  So stop the personal attacks on my criticism of this body of work.

  Your messages have consistently denigrated other peoples products and
their reasons for recommending simplicity in engineering design.

  This is *despite* the clear agreement of me and others that the RADIUS
model should be updated to meet your needs.

  If you want to keep this on a technical level, the only disagreement
we have is whether or not the updated model is described in this
document or in another one.

  Since the WG already has a document that extends RADIUS, I don't see
why that text should be in a BCP.  Just update the extension document,
and let the BCP move forward.

  Merging the two documents into one would require a charter update, as
both have charter milestones.  If you really want that to happen, stop
trying to "fix" the BCP, and propose instead that the WG be
re-chartered.  If you don't want to merge the two documents, then you
cannot have any objections to the BCP, as all of your concerns are
addressed in the extensions document.

  Alan DeKok.

Delivery-date: Fri, 22 Jan 2010 23:45:37 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Fri, 22 Jan 2010 18:45:00 -0500

--Apple-Mail-9-281375154
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Jan 22, 2010, at 5:53 PM, Avi Lior wrote:

> The tone of your responses is what I find offensive....

I think that the participants in this discussion are effectively at an  
impasse, that is to say they are talking past each other, attempting  
to make and re-make their points without actually listening to  
others.  That causes patience to fray and the tone to become "edgy".   
Let's try to dial this down a little.

> One would start wondering what is the purpose of your posts...

I think there may be multiple agendas to "protect" something, and as  
is sadly too often the case in standards body debates, the purpose of  
the debate is to "win", not to edify.

> ... the chairs and AD are obviously happy with this...

I see no evidence that the chairs or AD are *happy* about this.    
Bernard has already issued a tongue-in-cheek remark about the  
"frankness" of the discussion.  That was a polite hint.

> ...I take you to the BAD email discussion with Glen.

Exactly why are you attempting to drag poor Glen into this debate?  :-)

--Apple-Mail-9-281375154
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 22, 2010, at 5:53 PM, Avi Lior wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>The tone of your responses is what I find offensive....<br></div></blockquote><div><br></div><div>I think that the participants in this discussion are effectively at an impasse, that is to say they are talking past each other, attempting to make and re-make their points without actually listening to others. &nbsp;That causes patience to fray and the tone to become "edgy". &nbsp;Let's try to dial this down a little.</div><div><br></div><blockquote type="cite"><div>One would start wondering what is the purpose of your posts...</div></blockquote><div><br></div>I think there may be multiple agendas to "protect" something, and as is sadly too often the case in standards body debates, the purpose of the debate is to "win", not to edify.<br><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000">...</font> the chairs and AD are obviously happy with this...</div></blockquote><div><br></div><div>I see no evidence that the chairs or AD are *happy* about this. &nbsp; Bernard has already issued a tongue-in-cheek remark about the "frankness" of the discussion. &nbsp;That was a polite hint.</div><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000">..</font>.I take you to the BAD email discussion with Glen.</div></blockquote><div><br></div><div>Exactly why are you attempting to drag poor Glen into this debate? &nbsp;:-)</div><div><br></div></div><br></body></html>
--Apple-Mail-9-281375154--

Delivery-date: Fri, 22 Jan 2010 22:54:09 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>, David Nelson <[email-masked]>, Bernard Aboba <[email-masked]>, "Dan (Dan) Romascanu" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Glen Zorn <[email-masked]>
Date: Fri, 22 Jan 2010 17:53:06 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

The tone of your responses is what I find offensive....

No Alan, the purpose of all my post it to get the document to be the best possible document.  One would start wondering what is the purpose of your posts...is it to protect your implementation, you beloved FreeRadius...hmmmmm I think it is.

We have seen this type of shameless self promoting from you before: one just needs to look at the section 2.1.2 of RFC5080 with its shameless taunting of what a wonderful job FreeRadius did.  NOT really actually ... a pretty obvious non-novel solution.  Such text has no place in an RFC. 

I am trying to keep this professional and not personal. You persist with personal, patronizing attacks on me and my comments...but if you want to continue down the lines of personal attacks and the chairs and AD are obviously happy with this...then I have better things to do.

If I were the only one that is raising these issues I would just walk away.  But I am NOT the only one.  So stop the personal attacks on my criticism of this body of work.

And to Bernard, and David act like chairs.

And to Dan, Bernard, David and Alan....I take you to the BAD email discussion with Glen. This is a caustic WG...Great job guys.

On 22-01-2010, at 15:29 , Alan DeKok wrote:

> Avi Lior wrote:
>> Can we start with this then...
> 
>  I see your false dichotomy and raise you one:
> 
>  Is the purpose of your post to be intentionally offensive, or did you
> simply not see the dozens of posts explaining the document?
> 
>  Alan DeKok.

Delivery-date: Fri, 22 Jan 2010 20:50:35 +0000
Date: Fri, 22 Jan 2010 12:46:42 -0800
To: Alan DeKok <[email-masked]>
From: Ignacio Goyret <[email-masked]>
Subject: Re: FW: Review of draft-ietf-radext-status-server
Cc: Ignacio Goyret <[email-masked]>, Bernard Aboba <[email-masked]>, [email-masked]

At 09:35 PM 1/22/2010 +0100, Alan DeKok wrote:
>Ignacio Goyret wrote:
>> That assumes that the client was the one actually sending
>> the Status-Server. It could have been an attacker.
>> 
>> A client has very little to use to validate an incoming Access-Request
>> that was generated as a response to an Status-Server.
>
>  Hmm... OK.
>
>> IOW, a server responding to a Status-Server sent to its auth port
>> may unintentionally authenticate a bogus session.
>
>  This requires that the attacker obtain the Request Authenticator from
>the Access-Request, put it into a Status-Server, and send that to the
>server before it receives the Access-Request.
>
>  It's possible, but hard.
>
>> That's why I say that using Access-Accept as a response to
>> anything other than an Access-* is dangerous.
>
>  The use of Message-Authenticator means that the attacker won't be able
>to sign the Status-Server, meaning the server won't respond.

Which means that the client MUST trust that the server was
properly written and/or configured and will not respond to
bogus Status-Server -- even if the client never generates
them.

A client has *no* reliable way to find out if an incoming
Access-Accept is for an Access-Request it sent or from an
Status-Server sent by an attacker (with a possibly problematic
server).

See why this is a slippery slope?

IMHO, people should be advised to NOT use this method of
checking the servers.

-Ignacio

Delivery-date: Fri, 22 Jan 2010 20:36:37 +0000
Date: Fri, 22 Jan 2010 21:35:46 +0100
From: Alan DeKok <[email-masked]>
To: Ignacio Goyret <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: FW: Review of draft-ietf-radext-status-server

Ignacio Goyret wrote:
> That assumes that the client was the one actually sending
> the Status-Server. It could have been an attacker.
> 
> A client has very little to use to validate an incoming Access-Request
> that was generated as a response to an Status-Server.

  Hmm... OK.

> IOW, a server responding to a Status-Server sent to its auth port
> may unintentionally authenticate a bogus session.

  This requires that the attacker obtain the Request Authenticator from
the Access-Request, put it into a Status-Server, and send that to the
server before it receives the Access-Request.

  It's possible, but hard.

> That's why I say that using Access-Accept as a response to
> anything other than an Access-* is dangerous.

  The use of Message-Authenticator means that the attacker won't be able
to sign the Status-Server, meaning the server won't respond.

  We can put some more text into the document highlighting the necessity
for using Message-Authenticator.

  Alan DeKok.

Delivery-date: Fri, 22 Jan 2010 19:33:13 +0000
Date: Fri, 22 Jan 2010 11:28:28 -0800
To: Alan DeKok <[email-masked]>
From: Ignacio Goyret <[email-masked]>
Subject: Re: FW: Review of draft-ietf-radext-status-server
Cc: Bernard Aboba <[email-masked]>, [email-masked], Ignacio Goyret <[email-masked]>

>
>> The overloading of Access-Accept and Accounting-Response for
>> this purpose (response to a Server-Status command) is a bit
>> disconcerting and quite dangerous since it opens the door
>> for potentially bogus authentication.
>
>  I'm not sure why.  The response packets are signed with the Request
>Authenticator of the request.  i.e. the client *knows* that the
>Access-Accept is in response to a Status-Server. So it has no "user
>session" to authenticate.

That assumes that the client was the one actually sending
the Status-Server. It could have been an attacker.

A client has very little to use to validate an incoming Access-Request
that was generated as a response to an Status-Server.

IOW, a server responding to a Status-Server sent to its auth port
may unintentionally authenticate a bogus session.

That's why I say that using Access-Accept as a response to
anything other than an Access-* is dangerous.

Cheers,
-Ignacio

Delivery-date: Fri, 22 Jan 2010 13:52:07 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Fri, 22 Jan 2010 08:50:51 -0500

Avi Lior writes...

> I would think that the BCP that would be published today
> will be reflecting the new RADIUS designs but if that is not
> the case then we need to be clear about the applicability of
> this document.  I am okay with a BCP that applies to protecting
> traditional RADIUS usage but we need to be clear about it.
> 
> Can we start with this then...

I'm not sure what this really means.  I *suspect* that it provides a
convenient way to dismiss the document as being irrelevant when doing new
RADIUS work in "walled gardens" of "current technology" RADIUS server
deployments.

The thing about protocols is that they are simply words on paper.  A
*protocol* can not be said to have the property of multi-vendor
interoperability.  Only *implementations* of protocols can be tested to see
if interoperability is obtained.  Given that multi-vendor interoperability
is a key concern of IETF Standards-Track protocols, we can't dispense with
discussing implementations.

If a sufficient number of implementations take advantage of any given
property of a protocol, such the simplicity of that protocol's data model,
that property, e.g. the data model, becomes an integral element of the
protocol.

That's the case here.  The simple data model is an inherent property of the
RADIUS protocol by virtue of many implementations having relied upon it, if
for no other reason.  If we want to expand the data model, to be more rich
and complex, we therefore need to either revise or extend the protocol.

IMO, We can't simply say that the past is irrelevant, and we're going to
define a new version of the protocol that works well with a class of newly
designed implementations.  That would violate the basic tenets of
multi-vendor interoperability.

I'm all *for* expanding the RADIUS data model.  In fact, my personal
preferences in that regard extend beyond what the WG has achieved consensus
to support.  However, we need to do that within the constraints of a
reasonable protocol evolution methodology.  Either we add a protocol version
number negotiation methodology or we use an "escape" mechanism such as the
Extended Attribute format.

I think that simply ignoring the interoperability considerations of a
significant class of implementations, by labeling them "traditional",
legacy" or "historic" (or any other synonym) is the wrong thing to do.

Delivery-date: Fri, 22 Jan 2010 07:38:40 +0000
Date: Fri, 22 Jan 2010 08:38:16 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked], Ignacio Goyret <[email-masked]>
Subject: Re: FW: Review of draft-ietf-radext-status-server

> From: Ignacio Goyret [mailto:[email-masked]] 
...
> Anyway, I did a cursory review and have one technical comment
> and a few trivial editorial fixes:
> 
> 1) (tech comment) To be frank, both myself and our RADIUS engineers
> were quite surprised that the response to a Server-Status is not
> a code+1, or some other code like a fictitiuous "Server-Response".

  Yes.  I think it's because there was no "response" packet pre-defined.
 I suspect that the implementors didn't want to self-allocate.

> The overloading of Access-Accept and Accounting-Response for
> this purpose (response to a Server-Status command) is a bit
> disconcerting and quite dangerous since it opens the door
> for potentially bogus authentication.

  I'm not sure why.  The response packets are signed with the Request
Authenticator of the request.  i.e. the client *knows* that the
Access-Accept is in response to a Status-Server. So it has no "user
session" to authenticate.

> I know that it is past WGLC so dramatic changes are out of
> the question, but if nothing else, you should add some text
> explaining the decision for this overloading.

  OK.  I'll put something together.

  The rest of your comments are editorial, and will go into the document
as-is.

  Alan DeKok.

Delivery-date: Fri, 22 Jan 2010 07:29:42 +0000
Date: Fri, 22 Jan 2010 08:29:10 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Dave Nelson <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> Can we start with this then...

  I see your false dichotomy and raise you one:

  Is the purpose of your post to be intentionally offensive, or did you
simply not see the dozens of posts explaining the document?

  Alan DeKok.

Delivery-date: Fri, 22 Jan 2010 06:53:49 +0000
Date: Fri, 22 Jan 2010 07:53:02 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'Ignacio Goyret' <[email-masked]>, [email-masked],  [email-masked]
Subject: Re: Review of draft-ietf-radext-status-server

Bernard Aboba wrote:
> It had been my assumption that these codes had been implemented at the time
> that RFC 2865 was published (June 2000), but perhaps that was not the case. 

  IIRC, the Cistron RADIUS server had support for Status-Server in 1998
or 1999.  I believe the idea had originated from elsewhere, but I can't
find any reference for that right now.

  In any case, there are a number of implementations using it now.

  Alan DeKok.

Delivery-date: Fri, 22 Jan 2010 05:04:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed resolution to guidelines document
Date: Thu, 21 Jan 2010 21:03:19 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: "radext mailing list" <[email-masked]>

I think the suggested text is helpful.  

Joe

> Bernard Aboba wrote:
> > [BA] Is this referring to the "opaque data" case?
> 
>   Not really.  There are cases discussed in Appendix B where it's
deemed
> "acceptable" to have non-opaque data in complex types.
> 
>   I think the discussion on the list highlights that we could make it
> clearer that the SHOULD recommendations for using simple data types
are
> not "bats with which to attack people".
> 
>   Adding text to explain the meaning of "SHOULD" in excruciating
detail
> could negate a lot of the worries about the terrible impact of
> recommending simplicity.
> 
>   Alan DeKok.
> 
> --

Delivery-date: Fri, 22 Jan 2010 04:25:26 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Thu, 21 Jan 2010 23:24:26 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 20-01-2010, at 20:30 , Dave Nelson wrote:
>> 
> 
> RADIUS was not designed to represent complicated provisioning data, data
> sets with lots of inter-related elements, in any reasonably compact,
> efficient and standardized format.  That's why I personally hold out hope
> that the RADIUS Extended Attribute work will seriously address that issue
> and will do so soon.  To say that it's overdue is an understatement.

But things are now different.  So it goes back to stating clearly what is this document really about.  
Is it to protect existing legacy deployments or is it to provide guidelines to new RADIUS designs.

I would think that the BCP that would be published today will be reflecting the new RADIUS designs but if that is not the case then we need to be clear about the applicability of this document.  I am okay with a BCP that applies to protecting traditional RADIUS usage but we need to be clear about it.

Can we start with this then...

Delivery-date: Fri, 22 Jan 2010 01:34:24 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Ignacio Goyret'" <[email-masked]>
CC: <[email-masked]>, "'Alan DeKok'" <[email-masked]>, <[email-masked]>
Subject: RE: Review of draft-ietf-radext-status-server 
Date: Thu, 21 Jan 2010 17:33:59 -0800

Thanks for the review. 

The Status-Server (12) and Status-Client (13) codes were allocated for
experimental use in RFC 2865 Section 3, which states:

"   Codes 12 and 13 are reserved for possible use, but are not further
mentioned here."

It had been my assumption that these codes had been implemented at the time
that RFC 2865 was published (June 2000), but perhaps that was not the case. 

-----Original Message-----
From: Ignacio Goyret [mailto:[email-masked]] 
Sent: Thursday, January 21, 2010 3:30 PM
To: Bernard Aboba
Cc: [email-masked]; 'Alan DeKok'
Subject: Re: Review of draft-ietf-radext-status-server 

At 12:36 PM 1/11/2010 -0800, Bernard Aboba wrote:
>The document Use of Status-Server packets in the RADIUS protocol has now
completed RADEXT WG last call. 
> 
>Since the purpose of the document is to describe an existing deployed
protocol which was first implemented by Ascend Communications, we were
wondering if it would be possible for you to review the document for
accuracy. 
> 
>The document is available here:
>http://tools.ietf.org/html/draft-ietf-radext-status-server
> 

Hi guys,
Sorry for the delay, but I had to process some 6000 emails
after my vacation.

I don't know why you think that Ascend had implemented anything
like this. As far as I have been able to ascertain, neither our
RAS (MAX, TNT or APX) nor any of our RADIUS servers ever implemented
Server-Status. I even checked with the few folks still around
from the old Livingston (the creators of RADIUS) and got the
same story. Do you have any idea which product may have
implemented this? If you have any idea, let me know and
I'll try to find someone that can check the draft.

Anyway, I did a cursory review and have one technical comment
and a few trivial editorial fixes:

1) (tech comment) To be frank, both myself and our RADIUS engineers
were quite surprised that the response to a Server-Status is not
a code+1, or some other code like a fictitiuous "Server-Response".

The overloading of Access-Accept and Accounting-Response for
this purpose (response to a Server-Status command) is a bit
disconcerting and quite dangerous since it opens the door
for potentially bogus authentication.

I know that it is past WGLC so dramatic changes are out of
the question, but if nothing else, you should add some text
explaining the decision for this overloading.

2) page 6, section 2, 4th para:
                                                        vv
-   [RFC2865] Section 2.6.  "Keep-Alives" are sent when an downstream
+   [RFC2865] Section 2.6.  "Keep-Alives" are sent when a downstream
                                                        ^

3) page 6, section 2.1 title:

   Consider changing the title from:
       "Why Access-Request cannot be used"
   to something like:
       "Why Access-Request are not appropriate"

   This would make it more consistent with the 2.1.1 title
   which is a recommendation against, not a prohibition.

   Also, consider a similar change to the title section 2.2
   for the same reasons.

4) Page 10, first line:
                        vvvvvvv
-   same method as used for for calculating the Response Authenticator of
+   same method as used for calculating the Response Authenticator of
                        ^^^
5) page 20, section 6.2:

   The hex dump of the request is shown as:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   but it should be:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   (note change of "80" -> "50" in the 5th byte of the second line)

   Also, the response is wrong. It is shown as:

-----------------------(cut-here)-------------------------
      02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20 16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   but should be:

-----------------------(cut-here)-------------------------
      02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20
      16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   (two changes: "1a" -> "14" in the 4th byte of the first line,
    and a missing newline after "Length = 20").

HTH,
-Ignacio

Delivery-date: Fri, 22 Jan 2010 01:07:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: FW: Review of draft-ietf-radext-status-server 
Date: Thu, 21 Jan 2010 17:06:15 -0800

-----Original Message-----
From: Ignacio Goyret [mailto:[email-masked]] 
Sent: Thursday, January 21, 2010 3:30 PM
To: Bernard Aboba
Cc: [email-masked]; 'Alan DeKok'
Subject: Re: Review of draft-ietf-radext-status-server 

At 12:36 PM 1/11/2010 -0800, Bernard Aboba wrote:
>The document Use of Status-Server packets in the RADIUS protocol has now
completed RADEXT WG last call. 
> 
>Since the purpose of the document is to describe an existing deployed
protocol which was first implemented by Ascend Communications, we were
wondering if it would be possible for you to review the document for
accuracy. 
> 
>The document is available here:
>http://tools.ietf.org/html/draft-ietf-radext-status-server
> 

Hi guys,
Sorry for the delay, but I had to process some 6000 emails
after my vacation.

I don't know why you think that Ascend had implemented anything
like this. As far as I have been able to ascertain, neither our
RAS (MAX, TNT or APX) nor any of our RADIUS servers ever implemented
Server-Status. I even checked with the few folks still around
from the old Livingston (the creators of RADIUS) and got the
same story. Do you have any idea which product may have
implemented this? If you have any idea, let me know and
I'll try to find someone that can check the draft.

Anyway, I did a cursory review and have one technical comment
and a few trivial editorial fixes:

1) (tech comment) To be frank, both myself and our RADIUS engineers
were quite surprised that the response to a Server-Status is not
a code+1, or some other code like a fictitiuous "Server-Response".

The overloading of Access-Accept and Accounting-Response for
this purpose (response to a Server-Status command) is a bit
disconcerting and quite dangerous since it opens the door
for potentially bogus authentication.

I know that it is past WGLC so dramatic changes are out of
the question, but if nothing else, you should add some text
explaining the decision for this overloading.

2) page 6, section 2, 4th para:
                                                        vv
-   [RFC2865] Section 2.6.  "Keep-Alives" are sent when an downstream
+   [RFC2865] Section 2.6.  "Keep-Alives" are sent when a downstream
                                                        ^

3) page 6, section 2.1 title:

   Consider changing the title from:
       "Why Access-Request cannot be used"
   to something like:
       "Why Access-Request are not appropriate"

   This would make it more consistent with the 2.1.1 title
   which is a recommendation against, not a prohibition.

   Also, consider a similar change to the title section 2.2
   for the same reasons.

4) Page 10, first line:
                        vvvvvvv
-   same method as used for for calculating the Response Authenticator of
+   same method as used for calculating the Response Authenticator of
                        ^^^
5) page 20, section 6.2:

   The hex dump of the request is shown as:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   but it should be:

      0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
      ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
      da de 26 36 78 58

   (note change of "80" -> "50" in the 5th byte of the second line)

   Also, the response is wrong. It is shown as:

-----------------------(cut-here)-------------------------
      02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20 16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   but should be:

-----------------------(cut-here)-------------------------
      02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
      48 60 66 9c

       1 Code = Accounting-Response (5)
       1 ID = 179
       2 Length = 20
      16 Request Authenticator

      Attributes:
         None.
-----------------------(to-here)-------------------------

   (two changes: "1a" -> "14" in the 4th byte of the first line,
    and a missing newline after "Length = 20").

HTH,
-Ignacio

Delivery-date: Thu, 21 Jan 2010 08:17:43 +0000
Date: Thu, 21 Jan 2010 09:16:17 +0100
From: Alan DeKok <[email-masked]>
To: Hannes Tschofenig <[email-masked]>
CC: [email-masked]
Subject: Re: The RADIUS Design Model

Hannes Tschofenig wrote:
> The draft points to this policy language but only hints that there is a
> "simple" policy language in place that understands some basic data types and
> is also able to perform some simple processing actions. 

  RADIUS servers going back to Livingston have had a "simple" policy
language: the "users" file.  I'm not aware of any major server
implementation that has *less* functionality than that.

> The initially considered RADIUS model did not consider the policy aspect, I
> believe, and without describing of what existing implementations do in that
> space it will be difficult to come to an agreement.

  I'm not sure why.  Do you have specific issues with the document where
you think that the text doesn't apply to most RADIUS server
implementations?  If so, that would mean the text needs fixing.

> Unfortunately, it seems that the implementation internals and the
> anticipated deployment model have an impact on the way how RADIUS attributes
> are defined.

  I'm not sure how.  The document describes a high-level and simplistic
model of RADIUS attribute definitions.  If this model does not apply to
most implementations, the model needs to be fixed.

  As Dave has pointed out, RADIUS has *never* had a standard way to
describe and transport complex data structures.  So the model continues
the traditional practice of recommending simple structures.

  We cannot require the document to describe how to define complex
structures in RADIUS, because that would mean re-defining the protocol,
which is out of scope of the document.

> Unfortunately, I don't have a good idea on how to quickly solve the issues
> raised above. To make it worse I have two additional questions: 
> 
> 1) How come did
> http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/ got
> stuck again? 

  I'll avoid that question.

> 2) Why does nobody write a document with a punch of commonly used RADIUS
> data types that most of the implementations are using already? It would make
> the design of attributes so much easier! Every RADIUS dictionary
> implementation already offers more than just the basic data types. Maybe the
> specifications should catch up with implementation practice here. 

  That document could be useful.  I've pointed out before that the data
types defined in the specifications (e.g. "address") do not match the
implementations (e.g. ipaddr).

  But I'm wary of that effort.  The "guidelines" text which suggested
RFC 3162 defined an IPv6 address type was the target of much hostility.

  One reason I'm so surprised at the request to describe a more
complicated RADIUS model is that there's usually opposition to
describing the current model.  Since one depends on the other, it would
seem that describing a more complicated model is impossible, too.

  Alan DeKok.

Delivery-date: Wed, 20 Jan 2010 20:29:12 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Subject: RE: The RADIUS Design Model 
Date: Wed, 20 Jan 2010 12:28:32 -0800

------=_NextPart_000_0080_01CA99CC.14918660
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks for writing this up.   

As you note there are different considerations for a new attribute type,
depending on whether it is being sent or received, and what protocol
(Authentication vs. Accounting)  it is being used in.   The question is how
these considerations are reflected in Section 2.1.3 and Appendices A.   Do
you have changes that you'd like to propose?

In terms of review of existing types,  Section 2.1.1 goes over basic types
defined in existing RADIUS RFCs, and Appendix B surveys use of complex
attributes in existing RADIUS RFCs.  The focus is on existing RADIUS RFCs,
since the guidelines are primarily focused on design of attributes within
the standard RADIUS attribute space.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Wednesday, January 20, 2010 11:23 AM
To: [email-masked]
Subject: The RADIUS Design Model 

Hi all, 

sorry for joining this discussion so late.

In Section 2.1.3 the document says:

"
   One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes. 
"

We need to differentiate at least four cases here: 

1) RADIUS Server Data Provisioning

A RADIUS server consists of the RADIUS protocol implementation (often
implements a bunch of other protocols as well) and has access to a database.
Such a database can come in various flavors depending on the amount of data
being handled. In the simplest case it is a text file. 

When new data is added to the database and then it may already at this point
in time relate somehow to the data types being used when transmitted over
the wire. Everything can be encoded as a RADIUS string data type so that it
can be transmitted in RADIUS; so that's not really a problem. 

For testing purposes it might be useful to have additional a user interface
to enter data manually as well. This user interface might have certain
limitations regarding data types and hence some manual steps might be needed
before the data can be entered into the UI. This is particularly the case
with the encoding of "complex" attributes into a string. 

So, is this issue relevant for the document?
 
Yes, I think so. There is one sentence in the document of Section 2.1.3:
"
      * it is easier for the user to enter the data as well-known
        types, rather than complex structures; "

It is not clear to whom the term 'user' refers to. How easy or complex it is
for a person operating a RADIUS server to insert values into a database may
depend on a number of things, including support of provisioning scripts or
even user interfaces (largely for testing purposes).		
		
2) RADIUS Server Data Transmission to RADIUS Client

There are 2 cases that need to be considered here: 
a) RADIUS server just takes values from the database (more or less without
any further evaluation), and
b) RADIUS server dynamically decide what to return depending on a number of
criteria. This category falls a bit under the item (4). 

With item (a) there is not really big impact for the RADIUS server (and
consequently for the RADIUS design guidelines document) as long as the data
being fetched is already in the format that allows the RADIUS server to put
it into a RADIUS attribute. 

3) RADIUS Server Receiving Data from RADIUS Client
 
There are two approaches when it comes to the processing of incoming data on
the RADIUS server side: 

a) Treat everything as an opaque object and write to the some storage for
later processing. 

b) Perform processing within the RADIUS server itself. This approach is
useful when one wants to make some policy decisions and potentially needs to
interact with other systems in order to react accordingly in response to an
incoming request.

Which approach is the right one depends very much on the intented usage of
the received info. 

4) RADIUS Sever Policy Processing (i.e. the business logic)

Some RADIUS servers allow policy decisions to be made based, typically for
the purpose of authorization. These policy decisions need to be implemented
somehow in some programming language and if incoming attributes are used as
input to these policy decisions then their semantic needs to be understood.
How tighly the policy language itself is integrated into the core of the
RADIUS server implementation itself is an implementation choice.  

The draft points to this policy language but only hints that there is a
"simple" policy language in place that understands some basic data types and
is also able to perform some simple processing actions. 

I guess the disagreement is with step (3 - b) and particularly with (4). So,
I believe that there is at least some agreement here.

The initially considered RADIUS model did not consider the policy aspect, I
believe, and without describing of what existing implementations do in that
space it will be difficult to come to an agreement. We all have quite
different implementations that all vary from the "historically" defined
model (even thought it was never explicitly written down, I believe).
Unfortunately, it seems that the implementation internals and the
anticipated deployment model have an impact on the way how RADIUS attributes
are defined. I believe it makes sense to say that we want to give guidance
for standardization people to make it as simple as possible for implementers
(at least I hope so). In order to figure to figure out what worked well and
what didn't we would actually have to write code and to then see how
complicated it was (ideally in comparison to another approach). For some of
us it seems that the simplest implemention is to flatten the attributes out
into simpler onces. The down-side of that approach is that we run out of the
attribute space very quickly and defining these "simple" attributes already
requires a "complex attribute encoding" in the style of
http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/. So,
there is a problem. 

Unfortunately, I don't have a good idea on how to quickly solve the issues
raised above. To make it worse I have two additional questions: 

1) How come did
http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/ got
stuck again? 

2) Why does nobody write a document with a punch of commonly used RADIUS
data types that most of the implementations are using already? It would make
the design of attributes so much easier! Every RADIUS dictionary
implementation already offers more than just the basic data types. Maybe the
specifications should catch up with implementation practice here. 

Ciao
Hannes

PS: A totally independent issue: Can someone configure the mailing list so
that it displays the working group name in the Subject line? Makes it easier
to recognize the mails belonging to RADEXT and is inline with what other
working groups do.

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

------=_NextPart_000_0080_01CA99CC.14918660
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="winmail.dat"

------=_NextPart_000_0080_01CA99CC.14918660--

Delivery-date: Wed, 20 Jan 2010 19:20:22 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Subject: The RADIUS Design Model 
Date: Wed, 20 Jan 2010 21:23:24 +0200

Hi all, 

sorry for joining this discussion so late.

In Section 2.1.3 the document says:

"
   One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes. 
"

We need to differentiate at least four cases here: 

1) RADIUS Server Data Provisioning

A RADIUS server consists of the RADIUS protocol implementation (often
implements a bunch of other protocols as well) and has access to a database.
Such a database can come in various flavors depending on the amount of data
being handled. In the simplest case it is a text file. 

When new data is added to the database and then it may already at this point
in time relate somehow to the data types being used when transmitted over
the wire. Everything can be encoded as a RADIUS string data type so that it
can be transmitted in RADIUS; so that's not really a problem. 

For testing purposes it might be useful to have additional a user interface
to enter data manually as well. This user interface might have certain
limitations regarding data types and hence some manual steps might be needed
before the data can be entered into the UI. This is particularly the case
with the encoding of "complex" attributes into a string. 

So, is this issue relevant for the document?
 
Yes, I think so. There is one sentence in the document of Section 2.1.3:
"
      * it is easier for the user to enter the data as well-known
        types, rather than complex structures;
"

It is not clear to whom the term 'user' refers to. How easy or complex it is
for a person operating a RADIUS server to insert values into a database may
depend on a number of things, including support of provisioning scripts or
even user interfaces (largely for testing purposes).		
		
2) RADIUS Server Data Transmission to RADIUS Client

There are 2 cases that need to be considered here: 
a) RADIUS server just takes values from the database (more or less without
any further evaluation), and 
b) RADIUS server dynamically decide what to return depending on a number of
criteria. This category falls a bit under the item (4). 

With item (a) there is not really big impact for the RADIUS server (and
consequently for the RADIUS design guidelines document) as long as the data
being fetched is already in the format that allows the RADIUS server to put
it into a RADIUS attribute. 

3) RADIUS Server Receiving Data from RADIUS Client
 
There are two approaches when it comes to the processing of incoming data on
the RADIUS server side: 

a) Treat everything as an opaque object and write to the some storage for
later processing. 

b) Perform processing within the RADIUS server itself. This approach is
useful when 
one wants to make some policy decisions and potentially needs to interact
with other systems in order to react accordingly in response to an incoming
request.

Which approach is the right one depends very much on the intented usage of
the received info. 

4) RADIUS Sever Policy Processing (i.e. the business logic)

Some RADIUS servers allow policy decisions to be made based, typically for
the purpose of authorization. These policy decisions need to be implemented
somehow in some programming language and if incoming attributes are used as
input to these policy decisions then their semantic needs to be understood.
How tighly the policy language itself is integrated into the core of the
RADIUS server implementation itself is an implementation choice.  

The draft points to this policy language but only hints that there is a
"simple" policy language in place that understands some basic data types and
is also able to perform some simple processing actions. 

I guess the disagreement is with step (3 - b) and particularly with (4). So,
I believe that there is at least some agreement here.

The initially considered RADIUS model did not consider the policy aspect, I
believe, and without describing of what existing implementations do in that
space it will be difficult to come to an agreement. We all have quite
different implementations that all vary from the "historically" defined
model (even thought it was never explicitly written down, I believe).
Unfortunately, it seems that the implementation internals and the
anticipated deployment model have an impact on the way how RADIUS attributes
are defined. I believe it makes sense to say that we want to give guidance
for standardization people to make it as simple as possible for implementers
(at least I hope so). In order to figure to figure out what worked well and
what didn't we would actually have to write code and to then see how
complicated it was (ideally in comparison to another approach). For some of
us it seems that the simplest implemention is to flatten the attributes out
into simpler onces. The down-side of that approach is that we run out of the
attribute space very quickly and defining these "simple" attributes already
requires a "complex attribute encoding" in the style of
http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/. So,
there is a problem. 

Unfortunately, I don't have a good idea on how to quickly solve the issues
raised above. To make it worse I have two additional questions: 

1) How come did
http://tools.ietf.org/wg/radext/draft-ietf-radext-extended-attributes/ got
stuck again? 

2) Why does nobody write a document with a punch of commonly used RADIUS
data types that most of the implementations are using already? It would make
the design of attributes so much easier! Every RADIUS dictionary
implementation already offers more than just the basic data types. Maybe the
specifications should catch up with implementation practice here. 

Ciao
Hannes

PS: A totally independent issue: Can someone configure the mailing list so
that it displays the working group name in the Subject line? Makes it easier
to recognize the mails belonging to RADEXT and is inline with what other
working groups do.

Delivery-date: Wed, 20 Jan 2010 16:51:17 +0000
Date: Wed, 20 Jan 2010 17:50:43 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Proposed resolution to guidelines document

Bernard Aboba wrote:
> [BA] Is this referring to the "opaque data" case?

  Not really.  There are cases discussed in Appendix B where it's deemed
"acceptable" to have non-opaque data in complex types.

  I think the discussion on the list highlights that we could make it
clearer that the SHOULD recommendations for using simple data types are
not "bats with which to attack people".

  Adding text to explain the meaning of "SHOULD" in excruciating detail
could negate a lot of the worries about the terrible impact of
recommending simplicity.

  Alan DeKok.

Delivery-date: Wed, 20 Jan 2010 15:57:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
CC: "'radext mailing list'" <[email-masked]>
Subject: RE: Proposed resolution to guidelines document
Date: Wed, 20 Jan 2010 07:58:00 -0800

Alan said:

How about adding some text to Section 2.1.3:

"  There may be situations where complex attributes are beneficial,
because they reduce complexity in the non-RADIUS systems.
Unfortunately, there are no "hard and fast" rules for where the
complexity would best be located.  Each situation has to be decided on a
case-by-case basis."

[BA] Is this referring to the "opaque data" case?  Elsewhere in 2.1.3 it
talks about these attribute being defined as type "String":

   If the RADIUS Server simply passes the contents of an attribute to
   some non-RADIUS portion of the network, then the data is opaque, and
   SHOULD be defined to be of type String.  A concrete way of judging
   this requirement is whether or not the attribute definition in the
   RADIUS document contains delineated fields for sub-parts of the data.
   If those fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.

Delivery-date: Wed, 20 Jan 2010 15:53:45 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
CC: "'Joseph Salowey \(jsalowey\)'" <[email-masked]>, "'radext mailing list'" <[email-masked]>
Subject: RE: Proposed resolution to Issue 325
Date: Wed, 20 Jan 2010 07:53:22 -0800

Alan said:

"  I think that's partially covered by saying "changes CAN be required".

  Do we need specific text saying how new types can be entered as strings?"

That was one of the points made in Issue #325 -- that it is possible to
enter 
any attribute type as a string on the server, without a dictionary change.  
Of course, code changes can be necessary for receiving a new type,
both with respect to the dictionary as well as policy languages. 

Delivery-date: Wed, 20 Jan 2010 13:30:13 +0000
Date: Wed, 20 Jan 2010 14:29:36 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Proposed resolution to guidelines document

Alan DeKok wrote:
> Bernard Aboba wrote:
>> Do these changes address Issue #325?  
>   (D) Not addressed.  We seem to disagree on the utility of the
> recommendations.

  How about adding some text to Section 2.1.3:

  There may be situations where complex attributes are beneficial,
because they reduce complexity in the non-RADIUS systems.
Unfortunately, there are no "hard and fast" rules for where the
complexity would best be located.  Each situation has to be decided on a
case-by-case basis.

  Alan DeKok.

Delivery-date: Wed, 20 Jan 2010 12:31:06 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Wed, 20 Jan 2010 07:30:27 -0500
Wojciech Dec writes...

> Just by making attributes simple does not mean that the complexity
> of representing an elaborate data structure goes away - it's moved
> elsewhere. Furthermore, no Radius RFC does the job satisfactorily...

RADIUS was not designed to represent complicated provisioning data, data
sets with lots of inter-related elements, in any reasonably compact,
efficient and standardized format.  That's why I personally hold out hope
that the RADIUS Extended Attribute work will seriously address that issue
and will do so soon.  To say that it's overdue is an understatement.

Delivery-date: Wed, 20 Jan 2010 08:20:33 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Wed, 20 Jan 2010 09:19:29 +0100
From: "Wojciech Dec (wdec)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Dave Nelson" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: 19 January 2010 21:45
> To: Wojciech Dec (wdec)
> Cc: Dave Nelson; [email-masked]
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> Wojciech Dec (wdec) wrote:
> > Yes, it was intentional because:
> > a) Expressing complex data using simple attributes 
> generally requires 
> > an elaborate rule set to be present,
> 
>   A raft of existing RFCs would seem to disprove that idea.

Just by making attributes simple does not mean that the complexity of
representing an elaborate data structure goes away - it's moved
elsewhere. 
Furthermore, no Radius RFC does the job satisfactorily, vide rfc 5090. 

-Woj.

Delivery-date: Wed, 20 Jan 2010 07:31:28 +0000
Date: Wed, 20 Jan 2010 08:30:45 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "'Joseph Salowey (jsalowey)'" <[email-masked]>,  'radext mailing list' <[email-masked]>
Subject: Re: Proposed resolution to Issue 325

Bernard Aboba wrote:
> One thing I noticed in Section 2.1.3 was the following sentence:
> 
> " For data types not  supported by current RADIUS server dictionaries,
> changes to the
>    dictionary code can be required in order to allow the new type to be
> supported by 
>    and configured on the RADIUS server. "
> 
> In Issue #325, it was pointed out that new data types can initially be sent
> by a RADIUS server by configuring them as Strings.  So code changes are
> required only to enable RADIUS server to receive and parse the new data
> types, not to send them.  Of course, changes to the dictionary are necessary
> to improve the convenience with which the new data types can be entered.  

  I think that's partially covered by saying "changes CAN be required".

  Do we need specific text saying how new types can be entered as strings?

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 21:26:11 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Joseph Salowey \(jsalowey\)'" <[email-masked]>
CC: "'radext mailing list'" <[email-masked]>
Subject: RE: Proposed resolution to Issue 325
Date: Tue, 19 Jan 2010 13:25:30 -0800

------=_NextPart_000_00EF_01CA990A.DF6659F0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

One thing I noticed in Section 2.1.3 was the following sentence:

" For data types not  supported by current RADIUS server dictionaries,
changes to the
   dictionary code can be required in order to allow the new type to be
supported by 
   and configured on the RADIUS server. "

In Issue #325, it was pointed out that new data types can initially be sent
by a RADIUS server by configuring them as Strings.  So code changes are
required only to enable RADIUS server to receive and parse the new data
types, not to send them.  Of course, changes to the dictionary are necessary
to improve the convenience with which the new data types can be entered.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Tuesday, January 19, 2010 10:55 AM
To: Joseph Salowey (jsalowey)
Cc: Bernard Aboba; radext mailing list
Subject: Re: Proposed resolution to Issue 325

Joseph Salowey (jsalowey) wrote:
 After seeing all the
> discussion on the list, I think there still is some question over when 
> to use complex/new data types and when not to.

  There are few "hard and fast" rules.

>  I'm not sure this is easily resolved.

  I agree.

>  The document favors reducing complexity in certain aspects of server 
> implementation.  This may be appropriate for some cases, but in others 
> it may be appropriate to reduce complexity in another area, such as on 
> the NAS.  The document doesn't seem to be very clear on this, but 
> perhaps it doesn't intend to or need to be.

  I welcome *any* text that makes simple && clear recommendations.

  Alan DeKok.

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

------=_NextPart_000_00EF_01CA990A.DF6659F0
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="winmail.dat"

------=_NextPart_000_00EF_01CA990A.DF6659F0--

Delivery-date: Tue, 19 Jan 2010 20:46:16 +0000
Date: Tue, 19 Jan 2010 21:45:18 +0100
From: Alan DeKok <[email-masked]>
To: "Wojciech Dec (wdec)" <[email-masked]>
CC: Dave Nelson <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Wojciech Dec (wdec) wrote:
> Yes, it was intentional because:
> a) Expressing complex data using simple attributes generally requires an
> elaborate rule set to be present,

  A raft of existing RFCs would seem to disprove that idea.

> B) it was a rather flippant remark

  I suppose if you don't care that what you say is true, flippant
remarks are apropos.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 19:04:49 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 20:04:22 +0100
From: "Wojciech Dec (wdec)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Dave Nelson" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: 19 January 2010 17:15
> To: Wojciech Dec (wdec)
> Cc: Dave Nelson; [email-masked]
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> Wojciech Dec (wdec) wrote:
> > Having a BCP document which states "don't do it", along with some 
> > dubious arguments (eg security) really doesn't help.
> 
>   You carefully deleted the real argument that I had in my message:
> 
> >>  It *does* recommend against complex systems where simpler 
> ones would 
> >> suffice.  This is an engineering practice going back 50+ years.
> 
>   Was that intentional, or accidental?

Yes, it was intentional because:
a) Expressing complex data using simple attributes generally requires an
elaborate rule set to be present, which happens to be where the
complexity is. It so happens that radius doesn't robustly define such
rules, and even simple ones like tags are flagged as an issue (in the
BCP no less). Thus using simple attributes actually makes the system
(composed of protocol + whatever sits on top) more complex and less
robust because it's the custom "on top" piece that has to encode any
such rules. The BCP doesn't hence provide useful guidance on how simple
attributes can be constructed to do something more complex, but we know
that.
B) it was a rather flippant remark

-Woj.
>   Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 18:55:26 +0000
Date: Tue, 19 Jan 2010 19:55:04 +0100
From: Alan DeKok <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  radext mailing list <[email-masked]>
Subject: Re: Proposed resolution to Issue 325

Joseph Salowey (jsalowey) wrote:
 After seeing all the
> discussion on the list, I think there still is some question over when
> to use complex/new data types and when not to.

  There are few "hard and fast" rules.

>  I'm not sure this is easily resolved.

  I agree.

>  The document favors reducing complexity in certain
> aspects of server implementation.  This may be appropriate for some
> cases, but in others it may be appropriate to reduce complexity in
> another area, such as on the NAS.  The document doesn't seem to be very
> clear on this, but perhaps it doesn't intend to or need to be.  

  I welcome *any* text that makes simple && clear recommendations.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 18:42:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed resolution to Issue 325
Date: Tue, 19 Jan 2010 10:41:20 -0800
To: "Bernard Aboba" <[email-masked]>
Cc: "radext mailing list" <[email-masked]>

For the most part the revision looks OK.  I'm OK with recommending to
try to use existing types and resort to complex/new types if there is a
compelling reason not to use the basic types. After seeing all the
discussion on the list, I think there still is some question over when
to use complex/new data types and when not to.  I'm not sure this is
easily resolved.  The document favors reducing complexity in certain
aspects of server implementation.  This may be appropriate for some
cases, but in others it may be appropriate to reduce complexity in
another area, such as on the NAS.  The document doesn't seem to be very
clear on this, but perhaps it doesn't intend to or need to be.  

Cheers,

Joe

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Bernard Aboba
> Sent: Tuesday, January 19, 2010 9:16 AM
> To: Joseph Salowey (jsalowey)
> Cc: 'radext mailing list'
> Subject: Re: Proposed resolution to Issue 325
> 
> Do the changes made below address your issue?
> http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt
> 
> 
> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Tuesday, January 19, 2010 9:12 AM
> To: Bernard Aboba
> Cc: 'radext mailing list'
> Subject: Re: Proposed resolution to guidelines document
> 
> Bernard Aboba wrote:
> > Do these changes address Issue #325?
> 
>   Comments:
> 
>   (A) addressed by updated text on "new" data types, rather than
> "complex" types
> 
>   (B) addressed by moving the text to the security section, and
> replacing discussion of "application" with "other systems".  Also
> addressed security issues of complex types by noting more clearly that
> *change* has security implications.
> 
>   (C) previously fixed
> 
>   (D) Not addressed.  We seem to disagree on the utility of the
> recommendations.
> 
>   (E) previously answered && acknowledged as closed on-list.
> 
>   Alan DeKok.
> 
> 
> --

Delivery-date: Tue, 19 Jan 2010 18:22:38 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 13:21:54 -0500

On Jan 19, 2010, at 12:24 PM, Wojciech Dec (wdec) wrote:

> It comes down to what "tradional" means.

Traditional means what RFC 2865 *says*, exclusive of what various  
people assume / assert it allows by virtue of what it fails explicitly  
prohibit.

> Legacy is not too far off a similar word, so what's wrong with  
> saying "the recommendation
> of this BCP are applicable in deployements that utilize legacy  
> RADIUS servers/clients...."?

Why would we want to limit the scope in *that* way?  Legacy is close  
to "historic" and I don't think that the IETF has consensus to dismiss  
a class of RADIUS deployments as "legacy", "historic" or generally of  
lesser relevance.

> BTW The original comment said "The IETF has a process where one  
> document
> can be marked as "updating" another", in the context of the BCP and
> extended attributes drafts. That doesn't leave much room for  
> misinterpretation.

You're parsing specific words in a single reply out of a very long  
thread, as if they were court testimony or holy writ.  I'm telling you  
*why* the documents are broken down the way they are, as matter of WG  
consensus.

What Alan means is that we need not be overly concerned about what the  
BCP might inadvertently be construed to say about the usage of  
Extended Attributes, because the Extended Attributes document will  
provide its *own* usage guidelines for those attributes.  Nothing more.

Delivery-date: Tue, 19 Jan 2010 17:25:08 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 18:24:28 +0100
From: "Wojciech Dec (wdec)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: 19 January 2010 17:08
> To: [email-masked]
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> On Jan 19, 2010, at 10:56 AM, Wojciech Dec (wdec) wrote:
> 
> > Given that an update to the BCP is planned before it's even been 
> > published makes one wonder as to whether it's good to have it 
> > published in its current form. Which this thread is all about.
> 
> I think you misunderstood Alan's comment.  The WG arrived at 
> the consensus position that the BCP should address 
> "traditional" RADIUS only and that any guidelines for the 
> Extended Attribute format usage should be included in that 
> document.  This is a document modularity and separation of 
> concerns issue, not a statement about the correctness or 
> longevity of the BCP.

It comes down to what "tradional" means. Legacy is not too far off a
similar word, so what's wrong with saying "the recommendation of this
BCP are applicable in deployements that utilize legacy RADIUS
servers/clients...."?

BTW The original comment said "The IETF has a process where one document
can be marked as "updating" another", in the context of the BCP and
extended attributes drafts. That doesn't leave much room for
misinterpretation.

-Woj.

> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Tue, 19 Jan 2010 17:16:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
CC: "'radext mailing list'" <[email-masked]>
Subject: Re: Proposed resolution to Issue 325
Date: Tue, 19 Jan 2010 09:15:40 -0800

Do the changes made below address your issue?
http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, January 19, 2010 9:12 AM
To: Bernard Aboba
Cc: 'radext mailing list'
Subject: Re: Proposed resolution to guidelines document

Bernard Aboba wrote:
> Do these changes address Issue #325?  

  Comments:

  (A) addressed by updated text on "new" data types, rather than
"complex" types

  (B) addressed by moving the text to the security section, and
replacing discussion of "application" with "other systems".  Also
addressed security issues of complex types by noting more clearly that
*change* has security implications.

  (C) previously fixed

  (D) Not addressed.  We seem to disagree on the utility of the
recommendations.

  (E) previously answered && acknowledged as closed on-list.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 17:12:50 +0000
Date: Tue, 19 Jan 2010 18:12:24 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Proposed resolution to guidelines document

Bernard Aboba wrote:
> Do these changes address Issue #325?  

  Comments:

  (A) addressed by updated text on "new" data types, rather than
"complex" types

  (B) addressed by moving the text to the security section, and
replacing discussion of "application" with "other systems".  Also
addressed security issues of complex types by noting more clearly that
*change* has security implications.

  (C) previously fixed

  (D) Not addressed.  We seem to disagree on the utility of the
recommendations.

  (E) previously answered && acknowledged as closed on-list.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 16:48:30 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'radext mailing list'" <[email-masked]>
Subject: RE: Proposed resolution to guidelines document
Date: Tue, 19 Jan 2010 08:48:13 -0800

Do these changes address Issue #325?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Tuesday, January 19, 2010 5:25 AM
To: 'radext mailing list'
Subject: Proposed resolution to guidelines document

  I have put a proposed draft on my web site.  It *should* address the
(cough) minor comments discussed here:

http://git.freeradius.org/ietf/10-11-diff.html

http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

  Changes are:

1) delete unused definition of RADIUS proxy as pointed out by Avi

2) add missing line as pointed out by Avi

3) change text about "complex" types to "new" types.

4) move "Complex attributes and security" to the "Security" section

5) remove all text referencing "applications" from that section,
   and change the text to "other, non-RADIUS systems".  This makes
   the text generic enough to apply to application layers, or to
   the practice of storing RADIUS data in SQL tables

6) add text about modern systems:

  Some systems permit complex attributes to be defined via a method	
  that is more capable than traditional RADIUS dictionaries.  These	
  systems can reduce the security threat of new types significantly,	
  but they do not remove it entirely.	

7) it doesn't address Joe's comments or Bernard's suggestion.  That
   text will come later.

  I believe that this addresses *all* of controversial points.  The
document no longer relies on traditional RADIUS dictionaries to motivate
its recommendations.  It no longer discusses *any* processing model of
RADIUS, other than to say that systems other than RADIUS may use the
data produced by RADIUS.

  All it says is "prefer simple types to complex ones, but allow complex
ones if everything else is worse".  And it says that change has risk.

  If this text is deemed to be not applicable to the majority of
"RADIUS" implementations, then I suggest that those systems are no
longer implementing RADIUS.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 16:14:57 +0000
Date: Tue, 19 Jan 2010 17:14:36 +0100
From: Alan DeKok <[email-masked]>
To: "Wojciech Dec (wdec)" <[email-masked]>
CC: Dave Nelson <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Wojciech Dec (wdec) wrote:
> Having a BCP document which states "don't do it", along with some
> dubious arguments (eg security) really doesn't help.

  You carefully deleted the real argument that I had in my message:

>>  It *does* recommend against complex systems where simpler ones
>> would suffice.  This is an engineering practice going back 50+ years.

  Was that intentional, or accidental?

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 16:08:17 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 11:07:45 -0500

On Jan 19, 2010, at 10:56 AM, Wojciech Dec (wdec) wrote:

> Given that an update to the BCP is planned before it's even been
> published makes one wonder as to whether it's good to have it  
> published
> in its current form. Which this thread is all about.

I think you misunderstood Alan's comment.  The WG arrived at the  
consensus position that the BCP should address "traditional" RADIUS  
only and that any guidelines for the Extended Attribute format usage  
should be included in that document.  This is a document modularity  
and separation of concerns issue, not a statement about the  
correctness or longevity of the BCP.

Delivery-date: Tue, 19 Jan 2010 15:57:08 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 16:56:39 +0100
From: "Wojciech Dec (wdec)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Dave Nelson" <[email-masked]>, <[email-masked]>

> 
>   Multiple people supporting the guidelines document have 

Who would that be?

> agreed that complex attributes belong in the "extended 
> attributes" document.  Use
> *that* to defend the push for complex attributes.

Having a BCP document which states "don't do it", along with some
dubious arguments (eg security) really doesn't help.

> 
> > Even after such design, one will have a BCP that says one thing and 
> > another doc something else. This will be confusing to 
> anyone trying to 
> > make sense of it.
> 
>   You're putting a pretty low bar on the intelligence of 
> anyone reading the RFCs.  The IETF has a process where one 
> document can be marked as "updating" another.  WG progress 
> shouldn't stop because one person is confused about how that works.

Given that an update to the BCP is planned before it's even been
published makes one wonder as to whether it's good to have it published
in its current form. Which this thread is all about.

-Woj.

>   Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 15:43:26 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 10:42:40 -0500

On Jan 19, 2010, at 9:35 AM, Wojciech Dec (wdec) wrote:

> It would be nice to give the customizers some structure/guidance  
> instead...

Exactly!  We appear to agree on the goal.  I think we may still  
disagree on the specific content of that guidance.  My recommendation  
for guidance content is the BCP (pretty much as it stands) for  
"traditional" RADIUS attributes and the RADUS Extended Attribute  
format for additional levels of customization.

Delivery-date: Tue, 19 Jan 2010 15:28:02 +0000
Date: Tue, 19 Jan 2010 16:27:26 +0100
From: Alan DeKok <[email-masked]>
To: "Wojciech Dec (wdec)" <[email-masked]>
CC: Dave Nelson <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Wojciech Dec (wdec) wrote:
> Well, I don't think anyone proposed that. Instead, the proposal at least
> as I understood it to be (and support), is that the design guidelines
> should not be used as bar/ban/stick on complex attributes design and
> should have text to that effect.

  It does not bar complex attributes.

  It *does* recommend against complex systems where simpler ones would
suffice.  This is an engineering practice going back 50+ years.

> The current set-up looks like to me like this: During the (undoubtedly
> lengthy) discussions around complex attributes under the "extended
> attributes" banner, someone will claim "these attributes don't work with
> my foobar radius server implementation and are against the BCP of the WG
> itself".

  Which will be false.

  Multiple people supporting the guidelines document have agreed that
complex attributes belong in the "extended attributes" document.  Use
*that* to defend the push for complex attributes.

> Even after such design, one will have a BCP that says one thing
> and another doc something else. This will be confusing to anyone trying
> to make sense of it.

  You're putting a pretty low bar on the intelligence of anyone reading
the RFCs.  The IETF has a process where one document can be marked as
"updating" another.  WG progress shouldn't stop because one person is
confused about how that works.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 14:36:48 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 15:35:58 +0100
From: "Wojciech Dec (wdec)" <[email-masked]>
To: "Dave Nelson" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Nelson
> Sent: 19 January 2010 14:39
> To: [email-masked]
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> > Woj> The BCP steers to protect more radius server *implementations*
> > and not protocol interoperability.
> 
> I think you perhaps underestimate the role that standards 
> play in maintaining multi-vendor interoperability, not only 
> at a given snap-shot in time, e.g. at a plug-fest, but over 
> time in the marketplace, such that various generations of 
> product implemented to the same standard continue to 
> interoperate over time -- in the case of long-standing 
> "legacy" protocols like RADIUS, over a very long time.

I think you're confusing protocol with implementation. An interoperable
protocol and a standard implementation are different things. One can
(and does!) have plenty of protocols that are multi-vendor
interoperabile without a standardized implementation, and one can have a
standard implementation that is NOT interoperable (case in hand, Radius
server implementation A does not support attribute Z which another
radius server implemented in the same way does).
To say it differently, whether one codes up a Radius server to use a
data-type cast dictionary or not, it is not what makes the server
interoperable with other Radius devices. 
> 
> > To put it in other words; if a radius server does not support an 
> > attribute that is deemed useful by an operator, it will get 
> changed, 
> > period.
> 
> One reason that customers like standards is that they provide 
> a "level playing field".  While it's true that customers 
> sometimes value increased or specific functionality over 
> standardization and interchangeability, in my experience they 
> will always opt for the more widely interoperable product 
> when it meets their needs.  There is an inherent value in a 
> strict standards process.

I see no point in defending an *implementation* as a standard, why do
you?

> 
> > The point is thus, that the main value of Radius is in what the 
> > protocol does and not entirely in in how it does it.
> 
> I disagree heartily.  The value in RADIUS (as defined in the 
> Standard-Track RFC series) is exactly in how it does it, at 
> least in terms of all of the on-the-wire encodings.  That's 
> what differentiates a standard protocol from a proprietary protocol.

As per my corrected mail, I meant "how Radius servers do it" (is the
"how" that doesn't matter)

> 
> > With the BCP, without a reference to "historic" or some 
> other term to 
> > describe that server segment, we're constraining the "how" for all 
> > time to come without giving a path to evolve the "what".
> 
> I don't think that the RADEXT WG is chartered to deprecate 
> "traditional"
> RADIUS, and its on-the-wire data model, to "historic" status. 
>  I will point out that the RADEXT WG indeed *has* a mechanism 
> for changing the "how".
> That mechanism is the RADIUS Extended Attribute document.

Well, I don't think anyone proposed that. Instead, the proposal at least
as I understood it to be (and support), is that the design guidelines
should not be used as bar/ban/stick on complex attributes design and
should have text to that effect. And, as already pointed out by Avi,
placing such work in the extended attribute doc without any change to
the current wording of the BCP is an issue.
> 
> My guess as to why that mechanism isn't universally seen as 
> "the way forward" is that (a) the draft is currently 
> stagnant, for lack of editorial initiative, and (b) there are 
> already implementations of the advanced features using the 
> traditional attribute format, in some cases in a way that the 
> BCP would not recommend.

An old IETF mantra used to say that running code matters. The fact that
there are multi-vendor production networks that use a galore of complex
attributes, albeit custom defined is perhpas evidence to how off-course
the WG has gone in this area. It would be nice to give the customizers
some structure/guidance instead...

> 
> We can easily address the former issue, by redirecting some 
> energy from this debate toward finishing the RADIUS Extended 
> Attributes document.
> Unfortunately, I see no easy way to alleviate the latter 
> issue.  Well, there
> *is* a way, I suppose, and that's to limit the scope of 
> applicability of the BCP.  I don't believe that's the "right 
> thing to do".

The current set-up looks like to me like this: During the (undoubtedly
lengthy) discussions around complex attributes under the "extended
attributes" banner, someone will claim "these attributes don't work with
my foobar radius server implementation and are against the BCP of the WG
itself". Even after such design, one will have a BCP that says one thing
and another doc something else. This will be confusing to anyone trying
to make sense of it.
Why don't you see this as an issue?

-Woj.

> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Tue, 19 Jan 2010 14:01:22 +0000
Date: Tue, 19 Jan 2010 15:00:58 +0100
From: Alan DeKok <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed resolution to guidelines document

Dave Nelson wrote:
> My concern with this solution is that it's more than an editorial revision,
> and potentially overturns some elements of RADEXT WG, IETF and IESG
> consensus.  If we are to consider changing the the document in such a way,
> can this *really* be handled as an RFC Editor Note?

  It's also a way to show that the alleged large problems can be
completely resolved with small changes.

  If the fixes are so small, the problems cannot be that large.

  Alan Dekok.

Delivery-date: Tue, 19 Jan 2010 13:43:52 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Proposed resolution to guidelines document
Date: Tue, 19 Jan 2010 08:43:43 -0500

Alan DeKok writes...

> The document no longer relies on traditional RADIUS dictionaries
> to motivate its recommendations.  It no longer discusses *any* 
> processing model of RADIUS, other than to say that systems other
> than RADIUS may use the data produced by RADIUS.
> 
>   All it says is "prefer simple types to complex ones, but allow
> complex ones if everything else is worse".  And it says that change
> has risk.
> 
>   If this text is deemed to be not applicable to the majority of
> "RADIUS" implementations, then I suggest that those systems are no
> longer implementing RADIUS.

My concern with this solution is that it's more than an editorial revision,
and potentially overturns some elements of RADEXT WG, IETF and IESG
consensus.  If we are to consider changing the the document in such a way,
can this *really* be handled as an RFC Editor Note?

Delivery-date: Tue, 19 Jan 2010 13:38:45 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 08:38:30 -0500

> Woj> The BCP steers to protect more radius server *implementations*
> and not protocol interoperability.

I think you perhaps underestimate the role that standards play in
maintaining multi-vendor interoperability, not only at a given snap-shot in
time, e.g. at a plug-fest, but over time in the marketplace, such that
various generations of product implemented to the same standard continue to
interoperate over time -- in the case of long-standing "legacy" protocols
like RADIUS, over a very long time.

> To put it in other words; if a radius server does not support an
> attribute that is deemed useful by an operator, it will get changed,
> period.

One reason that customers like standards is that they provide a "level
playing field".  While it's true that customers sometimes value increased or
specific functionality over standardization and interchangeability, in my
experience they will always opt for the more widely interoperable product
when it meets their needs.  There is an inherent value in a strict standards
process.

> The point is thus, that the main value of Radius is in what the protocol
> does and not entirely in in how it does it.

I disagree heartily.  The value in RADIUS (as defined in the Standard-Track
RFC series) is exactly in how it does it, at least in terms of all of the
on-the-wire encodings.  That's what differentiates a standard protocol from
a proprietary protocol.

> With the BCP, without a reference to "historic" or some other term
> to describe that server segment, we're constraining the "how" for all
> time to come without giving a path to evolve the "what".

I don't think that the RADEXT WG is chartered to deprecate "traditional"
RADIUS, and its on-the-wire data model, to "historic" status.  I will point
out that the RADEXT WG indeed *has* a mechanism for changing the "how".
That mechanism is the RADIUS Extended Attribute document.

My guess as to why that mechanism isn't universally seen as "the way
forward" is that (a) the draft is currently stagnant, for lack of editorial
initiative, and (b) there are already implementations of the advanced
features using the traditional attribute format, in some cases in a way that
the BCP would not recommend.

We can easily address the former issue, by redirecting some energy from this
debate toward finishing the RADIUS Extended Attributes document.
Unfortunately, I see no easy way to alleviate the latter issue.  Well, there
*is* a way, I suppose, and that's to limit the scope of applicability of the
BCP.  I don't believe that's the "right thing to do".

Delivery-date: Tue, 19 Jan 2010 13:25:10 +0000
Date: Tue, 19 Jan 2010 14:24:48 +0100
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Proposed resolution to guidelines document

  I have put a proposed draft on my web site.  It *should* address the
(cough) minor comments discussed here:

http://git.freeradius.org/ietf/10-11-diff.html

http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

  Changes are:

1) delete unused definition of RADIUS proxy as pointed out by Avi

2) add missing line as pointed out by Avi

3) change text about "complex" types to "new" types.

4) move "Complex attributes and security" to the "Security" section

5) remove all text referencing "applications" from that section,
   and change the text to "other, non-RADIUS systems".  This makes
   the text generic enough to apply to application layers, or to
   the practice of storing RADIUS data in SQL tables

6) add text about modern systems:

  Some systems permit complex attributes to be defined via a method	
  that is more capable than traditional RADIUS dictionaries.  These	
  systems can reduce the security threat of new types significantly,	
  but they do not remove it entirely.	

7) it doesn't address Joe's comments or Bernard's suggestion.  That
   text will come later.

  I believe that this addresses *all* of controversial points.  The
document no longer relies on traditional RADIUS dictionaries to motivate
its recommendations.  It no longer discusses *any* processing model of
RADIUS, other than to say that systems other than RADIUS may use the
data produced by RADIUS.

  All it says is "prefer simple types to complex ones, but allow complex
ones if everything else is worse".  And it says that change has risk.

  If this text is deemed to be not applicable to the majority of
"RADIUS" implementations, then I suggest that those systems are no
longer implementing RADIUS.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 13:15:36 +0000
Date: Tue, 19 Jan 2010 14:14:46 +0100
From: Alan DeKok <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: Avi Lior <[email-masked]>,  Dave Nelson <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Romascanu, Dan (Dan) wrote:
> Would it be possible for Alan and Avi to take it from this point of the
> discussion and try to write and agree on a few paragraphs of text which
> describe what this BCP covers and what is not covered and left out
> possibly for future work? 

  The document already says what it covers.  To summarize:

1) RADIUS has traditionally had a few simple data types which are used
   by most attributes (90% or more)

2) A small percentage of attributes have "complex" types that
   are not one of the "simple" types defined in (1)

3) The BCP recommends continuing practice (1) where possible

4) the BCP explicitly acknowledges that there are situations where
   practice (2) is acceptable.

5) the BCP does not forbid anyone from engaging in practice (2)

  That's really it.  I'm not sure how to reach a common ground that
excludes any of the above points.

  All of the discussion of dictionaries and server capabilities is
secondary to the above points.

  We *could* add text about "modern" servers.  It would look like:

---
  Many servers can define attributes via more powerful methods than the
traditional RADIUS dictionaries.  However, this capability does not
change the above recommendation to prefer simple types over complex ones.
---

  That's the point of contention.  We could *remove* all of the text in
the document about traditional dictionaries, and insert pages of text
describing how wonderful "modern"" systems are.  It doesn't *matter* how
capable or how incapable the implementations are.

  The BCP will still recommend simple designs over complex ones.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 10:13:18 +0000
Date: Tue, 19 Jan 2010 11:13:02 +0100
From: Alan DeKok <[email-masked]>
To: "Wojciech Dec (wdec)" <[email-masked]>
CC: Dave Nelson <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Wojciech Dec (wdec) wrote:
> It's not unreasonable to expect that whoever wants to use a complex
> attribute (against the recommendations of this BCP

  The BCP recommends against complex attributes when the traditional
data types would be sufficient for expressing the data.

  Where traditional data types are insufficient, the BCP allows complex
types.

> To put it in other words; if a radius server does not support an
> attribute that is deemed useful by an operator, it will get changed,
> period. 

  I agree.

> The point is thus, that the main value of Radius is in what the protocol
> does and not entirely in in how it does it. With the BCP, without a
> reference to "historic" or some other term to describe that server
> segment, we're constraining the "how" for all time to come without
> giving a path to evolve the "what".

  The BCP gives such a path: complex types are permitted.

  See Appendix B for a series of reviews of existing attributes.  The
reviews say things like:

... Therefore, this complex data type is acceptable in this situation.

  I have no idea how anyone can conclude that it forbids complex types.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 10:10:58 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 11:10:01 +0100
From: "Wojciech Dec (wdec)" <[email-masked]>
To: "Dave Nelson" <[email-masked]>, <[email-masked]>

Typo correction inline... 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
> Sent: 19 January 2010 10:40
> To: Dave Nelson; [email-masked]
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Dave Nelson
> > Sent: 19 January 2010 06:49
> > To: [email-masked]
> > Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> > 
> > > Which is fine but I think you have to document this distinction.
> > > That is a problem with this BCP only people who read these
> > long email
> > > threads will understand what is really going on.  If the
> > intent is to
> > > protect the existing radius base then we should be clear 
> about that.
> > 
> > The primary intent is to promote *extension* of the RADIUS protocol 
> > rather than *revision* of the RADIUS protocol.  That is to 
> say, to use 
> > well-accepted mechanisms for forward-backward protocol extensions, 
> > rather than simply revising the data model without any 
> concern about 
> > compatibility with existing deployments.  This is the way that 
> > IETF-Standards track protocols are "evolved", via extension, rather 
> > than via revision.  Certainly interoperability with a broad 
> range of 
> > implementations, some of which may qualify for the term 
> "legacy", is 
> > an important factor.  That's one reason that vendors like 
> to implement 
> > standards -- they don't expect them to change in 
> > non-backward-compatible ways over time.
> > 
> > There are examples of protocol revision in the IETF, of 
> course, such 
> > as IPv4 and IPv6, but that's not what we're about here.  We already 
> > have RADIUS V2 and it's called Diameter.
> > 
> > I fail to understand the point of most of the arguments 
> against this 
> > BCP, unless it's to "protect" a "revised"
> > dialect of RADIUS as implemented in some "modern" RADIUS server 
> > implementations.  If RADIUS has become fragmented into 
> > non-interoperable dialects, I think that would be very sad 
> indeed.  In 
> > that case, I don't see the advantage of
> 
> Woj> The BCP steers to protect more radius server 
> *implementations* and
> not protocol interoperability. That's evidenced by the talk 
> of Radius implementations of % figures in this thread.  
> It's not unreasonable to expect that whoever wants to use a 
> complex attribute (against the recommendations of this BCP 
> at this stage) will a) upgrade all their clients (1000s) 
> and b) check their radius server + make changes if needed. 
> Given that a) is a task of several orders of magnitude larger 
> than b), it would seem that the stance to protect old radius 
> server implementations at all costs is highly unbalanced. 
> To put it in other words; if a radius server does not support 
> an attribute that is deemed useful by an operator, it will 
> get changed, period. 
> The point is thus, that the main value of Radius is in what 
> the protocol does and not entirely in in how 
*servers* do it. With 
> the BCP, without a reference to "historic" or some other term 
> to describe that server segment, we're constraining the "how" 
> for all time to come without giving a path to evolve the "what".
> 
> -Woj.
> 
> > legitimizing that fragmentation by trying to "gut" the core 
> > recommendations of this BCP or to narrow its scope to some 
> "legacy" or 
> > "historic" segment of the RADIUS server market.
> > It seems to me that's where this discussion is ultimately 
> leading us.
> > 
> > Have I missed an important point somewhere?
> > 
> > 
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe' 
> in a single 
> > line as the message text body.

Delivery-date: Tue, 19 Jan 2010 09:40:50 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 10:40:22 +0100
To: "Dave Nelson" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Nelson
> Sent: 19 January 2010 06:49
> To: [email-masked]
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> > Which is fine but I think you have to document this distinction.
> > That is a problem with this BCP only people who read these 
> long email 
> > threads will understand what is really going on.  If the 
> intent is to 
> > protect the existing radius base then we should be clear about that.
> 
> The primary intent is to promote *extension* of the RADIUS 
> protocol rather than *revision* of the RADIUS protocol.  That 
> is to say, to use well-accepted mechanisms for 
> forward-backward protocol extensions, rather than simply 
> revising the data model without any concern about 
> compatibility with existing deployments.  This is the way 
> that IETF-Standards track protocols are "evolved", via 
> extension, rather than via revision.  Certainly 
> interoperability with a broad range of implementations, some 
> of which may qualify for the term "legacy", is an important 
> factor.  That's one reason that vendors like to implement 
> standards -- they don't expect them to change in 
> non-backward-compatible ways over time.
> 
> There are examples of protocol revision in the IETF, of 
> course, such as IPv4 and IPv6, but that's not what we're 
> about here.  We already have RADIUS V2 and it's called Diameter.
> 
> I fail to understand the point of most of the arguments 
> against this BCP, unless it's to "protect" a "revised" 
> dialect of RADIUS as implemented in some "modern" RADIUS 
> server implementations.  If RADIUS has become fragmented into 
> non-interoperable dialects, I think that would be very sad 
> indeed.  In that case, I don't see the advantage of 

Woj> The BCP steers to protect more radius server *implementations* and
not protocol interoperability. That's evidenced by the talk of Radius
implementations of % figures in this thread.  
It's not unreasonable to expect that whoever wants to use a complex
attribute (against the recommendations of this BCP will at this stage)
will a) upgrade all their clients (1000s) and b) check their radius
server + make changes if needed. Given that a) is a task of several
orders of magnitude larger than b), it would seem that the stance to
protect old radius server implementations at all costs is highly
unbalanced. 
To put it in other words; if a radius server does not support an
attribute that is deemed useful by an operator, it will get changed,
period. 
The point is thus, that the main value of Radius is in what the protocol
does and not entirely in in how it does it. With the BCP, without a
reference to "historic" or some other term to describe that server
segment, we're constraining the "how" for all time to come without
giving a path to evolve the "what".

-Woj.

> legitimizing that fragmentation by trying to "gut" the core 
> recommendations of this BCP or to narrow its scope to some 
> "legacy" or "historic" segment of the RADIUS server market.  
> It seems to me that's where this discussion is ultimately leading us.
> 
> Have I missed an important point somewhere?
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Tue, 19 Jan 2010 09:28:07 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 10:27:08 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Dave Nelson" <[email-masked]>
Cc: <[email-masked]>

Would it be possible for Alan and Avi to take it from this point of the
discussion and try to write and agree on a few paragraphs of text which
describe what this BCP covers and what is not covered and left out
possibly for future work? 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Avi Lior
> Sent: Tuesday, January 19, 2010 6:06 AM
> To: Dave Nelson
> Cc: [email-masked]
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> See inline...
> 
> On 18-01-2010, at 04:08 , Dave Nelson wrote:
> 
> >> Complex attributes may also be added to the dictionary 
> such that the 
> >> RADIUS server does not require code changes to process 
> these attributes.
> > 
> > This may be true of a class of newer RADIUS server implementations, 
> > those with a "dynamic" data dictionary, but it is not true 
> of another 
> > class of more "traditional" RADIUS servers, and it's those 
> that this 
> > section intends to address.
> 
> It should be made clear.  Maybe it says that somewhere in the 
> document. 
> 
> As a minimum it must be clearly stated that the intent of the 
> BCP is to protect legacy. 
> "the recommendation of this BCP are applicable in 
> deployements that utilize legacy RADIUS servers/clients...."
> 
> Define legacy RADIUS servers/clients and I would be okay.
> 
> IMO the BCP should make a distinction and address both legacy 
> and newer RADIUS servers.  Bu
> 
> > 
> > As I said in a previous post, the plan is to recommend (via 
> this BCP) 
> > that newly design RADIUS attributes not contribute to rendering a 
> > significant installed base of deployed RADIUS servers 
> effectively obsolete.
> > 
> > If we were talking about VSAs, this wouldn't be a concern.  We're 
> > talking about standards-tack attributes.
> Okay then we should make sure that the document makes this clear.
> 
> Perhaps we can clarify this -- In section 2.1 and section 2.2 
> or in section 2.0
> 
> >  If all you have to worry about is the class of "enhanced 
> capability" 
> > RADIUS servers, then I would agree.  In the IETF, we need to take a 
> > broader view, I think.
> Which is fine but I think you have to document this 
> distinction.  That is a problem with this BCP only people who 
> read these long email threads will understand what is really 
> going on.  If the intent is to protect the existing radius 
> base then we should be clear about that.  
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Tue, 19 Jan 2010 09:16:26 +0000
Date: Tue, 19 Jan 2010 10:15:52 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Dave Nelson <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
>>  i.e. 40% don't have "extended" capabilities.
> 
> 
> What do you mean by "extended" capabilities?

  Can we just stop this game?

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 08:16:38 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Dave Nelson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 19 Jan 2010 03:15:56 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

>  i.e. 40% don't have "extended" capabilities.

What do you mean by "extended" capabilities?

Delivery-date: Tue, 19 Jan 2010 07:38:36 +0000
Date: Tue, 19 Jan 2010 08:38:12 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Dave Nelson <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
>>  Stop lying about what I said.
> 
> In an email long ago I  wrote:
>>>> Not the old RADIUS model but rather the one that we are all living
>>>> with today.  That model is not really different then Diameter.
> 
> This was your reply to the above:
> 
>  40% (or more) of current RADIUS deployments would disagree.

  i.e. 40% don't have "extended" capabilities.

  This is *not* the same thing as saying that the other 60% lack
"traditional" capabilities, and are therefore not addressed by the document.

  Take a logic course.

> On 19-01-2010, at 14:44 , Alan DeKok wrote:
> 
> Can you explain why you think I was lying???

  There are two ways to lie convincingly.  One is to tell the truth, and
make it sound like a lie.  Another is to tell *part* of the truth, and
make it sound like the *whole* truth.

  On Jan. 14, I sent a message containing the text:

---
  As I have said repeatedly, the document addresses the capabilities of
100% of the deployments.
---

  Which directly refutes your claim that I said the document applies to
only a subset of the deployments.

  However, if you really believe that the document does not address
*any* capabilities of 60% of RADIUS deployments, then this is great
news!  You have just defined those deployments as *not* implementing
RADIUS.  Your objections to a *RADIUS* BCP are therefore no longer
applicable, and can be summarily rejected.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 07:23:38 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Dave Nelson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 19 Jan 2010 02:22:47 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

>  Stop lying about what I said.

In an email long ago I  wrote:
>>> Not the old RADIUS model but rather the one that we are all living
>>> with today.  That model is not really different then Diameter.

This was your reply to the above:

 40% (or more) of current RADIUS deployments would disagree.
On 19-01-2010, at 14:44 , Alan DeKok wrote:

Can you explain why you think I was lying???

> Avi Lior wrote:
>> The current state of RADIUS is not the legacy state that the BCP seems
>> to be about either. As you pointed out - it applies to 40% of the market.
> 
>  Stop lying about what I said.
> 
>  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 06:45:22 +0000
Date: Tue, 19 Jan 2010 07:44:36 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Dave Nelson <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> The current state of RADIUS is not the legacy state that the BCP seems
> to be about either. As you pointed out - it applies to 40% of the market.

  Stop lying about what I said.

  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 05:49:07 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 19 Jan 2010 00:48:46 -0500

> Which is fine but I think you have to document this distinction.
> That is a problem with this BCP only people who read these long
> email threads will understand what is really going on.  If the 
> intent is to protect the existing radius base then we should be
> clear about that.

The primary intent is to promote *extension* of the RADIUS protocol rather
than *revision* of the RADIUS protocol.  That is to say, to use
well-accepted mechanisms for forward-backward protocol extensions, rather
than simply revising the data model without any concern about compatibility
with existing deployments.  This is the way that IETF-Standards track
protocols are "evolved", via extension, rather than via revision.  Certainly
interoperability with a broad range of implementations, some of which may
qualify for the term "legacy", is an important factor.  That's one reason
that vendors like to implement standards -- they don't expect them to change
in non-backward-compatible ways over time.

There are examples of protocol revision in the IETF, of course, such as IPv4
and IPv6, but that's not what we're about here.  We already have RADIUS V2
and it's called Diameter.

I fail to understand the point of most of the arguments against this BCP,
unless it's to "protect" a "revised" dialect of RADIUS as implemented in
some "modern" RADIUS server implementations.  If RADIUS has become
fragmented into non-interoperable dialects, I think that would be very sad
indeed.  In that case, I don't see the advantage of legitimizing that
fragmentation by trying to "gut" the core recommendations of this BCP or to
narrow its scope to some "legacy" or "historic" segment of the RADIUS server
market.  It seems to me that's where this discussion is ultimately leading
us.

Have I missed an important point somewhere?

Delivery-date: Tue, 19 Jan 2010 05:28:43 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 19 Jan 2010 00:28:23 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

See inline...

On 18-01-2010, at 04:08 , Dave Nelson wrote:

>> Complex attributes may also be added to the dictionary such that the
>> RADIUS server does not require code changes to process these attributes.
> 
> This may be true of a class of newer RADIUS server implementations, those
> with a "dynamic" data dictionary, but it is not true of another class of
> more "traditional" RADIUS servers, and it's those that this section intends
> to address.
Okay...
> 
> As I said in a previous post, the plan is to recommend (via this BCP) that
> newly design RADIUS attributes not contribute to rendering a significant
> installed base of deployed RADIUS servers effectively obsolete.
> 
> If we were talking about VSAs, this wouldn't be a concern.  We're talking
> about standards-tack attributes.
Okay then we should make sure that the document makes this clear.
The problem is the document talks about SDOs.  SDO work on VSAs not standard track attributes. 

>From the abstract we have:
"reviewers of future RADIUS attribute specifications, both within the
   IETF as well as other Standards Development Organizations (SDOs)."

>  If all you have to worry about is the
> class of "enhanced capability" RADIUS servers, then I would agree.  In the
> IETF, we need to take a broader view, I think.
Which is fine but I think you have to document this distinction.  That is a problem with this BCP only people who read these long email threads will understand what is really going on.

Delivery-date: Tue, 19 Jan 2010 05:27:53 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Dave Nelson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 19 Jan 2010 00:26:54 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 19-01-2010, at 08:59 , Alan DeKok wrote:

> Dave Nelson wrote:
>>>  The document would cease to be a RADIUS BCP.  It would become an SDO
>>> BCP, and would describe practices that are SDO specific.
>>> 
>>>  If you want such a document, go write it in an SDO.
>> 
>> I'm not sure that's the best possible advice, either.  The "preferred future
>> state" is a more unified RADIUS data model, not a more fragment one.
> 
>  I agree that's the preferred future state.  But the "extended
> attributes" document which defines IETF RADIUS complex types isn't finished.
> 
>  The guidelines document can therefore discuss nothing more than the
> current state of RADIUS: basic data types, and "ad hoc" complex types
> (RFC 4679, 5090, etc.)
The current state of RADIUS is not the legacy state that the BCP seems to be about either. As you pointed out - it applies to 40% of the market.  Lets me totally clear what this BCP is for....

> 
>  I have no objection to adding complex types in this WG.  But it hasn't
> happened yet, and the "guidelines" document isn't the place to define them.
> 
>  Alan DeKok.
> 
> --

Delivery-date: Tue, 19 Jan 2010 05:27:45 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Wojciech Dec (wdec)" <[email-masked]>, Dave Nelson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 19 Jan 2010 00:26:53 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 18-01-2010, at 19:10 , Alan DeKok wrote:

> Wojciech Dec (wdec) wrote:
>> This would precisely be what one calls an "implementation choice".
> 
>  Or "15 years of RADIUS practice".

Some people have evolved their RADIUS practice....

> 
>> I'd
>> again suggest that the Radius WG could do much better then trying to
>> deal with issues that are actually implementation issues, which does go
>> to the heart of a lot of the arguments on this thread.
> 
>  Then my position has not been sufficiently clear.
> 
>  The issue is whether the document should describe only a subset of
> implementations.

It is describing a subset -- and its not clear that its doing that.

> 
>  There have been repeated statements that the document describes a
> model which does not apply to current implementations.  These statements
> are false.

That is true.  Some vendors and deployments are totally happy with legacy RADIUS servers/clients.

> 
>  The follow-on requirement is to remove text which describes the
> traditional model, and to insert text which describes a "modern" model.
> The resulting document would describe a significantly reduced subset of
> RADIUS implementations.
If you want to cover legacy then be very explicit about that.

If you want to cover both then there is more work to do.

> 
>  The document would cease to be a RADIUS BCP.  It would become an SDO
> BCP, and would describe practices that are SDO specific.
> 
>  If you want such a document, go write it in an SDO.
IETF is an SDO by David's argument or yours - cant remember which.

But I would be okay if the document clearly stated in "Blinking 50 pt font" that it is applicable to deployements that utilize legacy RADIUS servers/clients....in the abstract and the applicability section.

>  Alan DeKok.

Delivery-date: Tue, 19 Jan 2010 04:07:24 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Mon, 18 Jan 2010 23:05:48 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

See inline...

On 18-01-2010, at 04:08 , Dave Nelson wrote:

>> Complex attributes may also be added to the dictionary such that the
>> RADIUS server does not require code changes to process these attributes.
> 
> This may be true of a class of newer RADIUS server implementations, those
> with a "dynamic" data dictionary, but it is not true of another class of
> more "traditional" RADIUS servers, and it's those that this section intends
> to address.

It should be made clear.  Maybe it says that somewhere in the document. 

As a minimum it must be clearly stated that the intent of the BCP is to protect legacy. 
"the recommendation of this BCP are applicable in deployements that utilize legacy RADIUS servers/clients...."

Define legacy RADIUS servers/clients and I would be okay.

IMO the BCP should make a distinction and address both legacy and newer RADIUS servers.  Bu

> 
> As I said in a previous post, the plan is to recommend (via this BCP) that
> newly design RADIUS attributes not contribute to rendering a significant
> installed base of deployed RADIUS servers effectively obsolete.
> 
> If we were talking about VSAs, this wouldn't be a concern.  We're talking
> about standards-tack attributes.
Okay then we should make sure that the document makes this clear.

Perhaps we can clarify this -- In section 2.1 and section 2.2 or in section 2.0

>  If all you have to worry about is the
> class of "enhanced capability" RADIUS servers, then I would agree.  In the
> IETF, we need to take a broader view, I think.
Which is fine but I think you have to document this distinction.  That is a problem with this BCP only people who read these long email threads will understand what is really going on.  If the intent is to protect the existing radius base then we should be clear about that.  

Delivery-date: Tue, 19 Jan 2010 01:00:23 +0000
Date: Tue, 19 Jan 2010 01:59:23 +0100
From: Alan DeKok <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Dave Nelson wrote:
>>   The document would cease to be a RADIUS BCP.  It would become an SDO
>> BCP, and would describe practices that are SDO specific.
>>
>>   If you want such a document, go write it in an SDO.
> 
> I'm not sure that's the best possible advice, either.  The "preferred future
> state" is a more unified RADIUS data model, not a more fragment one.

  I agree that's the preferred future state.  But the "extended
attributes" document which defines IETF RADIUS complex types isn't finished.

  The guidelines document can therefore discuss nothing more than the
current state of RADIUS: basic data types, and "ad hoc" complex types
(RFC 4679, 5090, etc.)

  I have no objection to adding complex types in this WG.  But it hasn't
happened yet, and the "guidelines" document isn't the place to define them.

  Alan DeKok.

Delivery-date: Mon, 18 Jan 2010 15:34:55 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Mon, 18 Jan 2010 10:34:00 -0500

>   The document would cease to be a RADIUS BCP.  It would become an SDO
> BCP, and would describe practices that are SDO specific.
> 
>   If you want such a document, go write it in an SDO.

I'm not sure that's the best possible advice, either.  The "preferred future
state" is a more unified RADIUS data model, not a more fragment one.

While SDOs are certainly free to follow specific guidelines for RADIUS work
that is SDO-specific, I'm not aware that we have SDO-specific RADIUS server
implementations.  Or at the very least, we would likely run into the same
set of issues when attempting to deploy these new attributes on legacy
RADIUS servers.  For that reason, I'm not sure such a "walled garden"
approach would really work.

Delivery-date: Mon, 18 Jan 2010 11:11:28 +0000
Date: Mon, 18 Jan 2010 12:10:55 +0100
From: Alan DeKok <[email-masked]>
To: "Wojciech Dec (wdec)" <[email-masked]>
CC: Dave Nelson <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Wojciech Dec (wdec) wrote:
> This would precisely be what one calls an "implementation choice".

  Or "15 years of RADIUS practice".

> I'd
> again suggest that the Radius WG could do much better then trying to
> deal with issues that are actually implementation issues, which does go
> to the heart of a lot of the arguments on this thread.

  Then my position has not been sufficiently clear.

  The issue is whether the document should describe only a subset of
implementations.

  There have been repeated statements that the document describes a
model which does not apply to current implementations.  These statements
are false.

  The follow-on requirement is to remove text which describes the
traditional model, and to insert text which describes a "modern" model.
 The resulting document would describe a significantly reduced subset of
RADIUS implementations.

  The document would cease to be a RADIUS BCP.  It would become an SDO
BCP, and would describe practices that are SDO specific.

  If you want such a document, go write it in an SDO.

  Alan DeKok.

Delivery-date: Mon, 18 Jan 2010 10:35:30 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Mon, 18 Jan 2010 11:34:22 +0100
To: "Dave Nelson" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Nelson
> Sent: 17 January 2010 21:08
> To: [email-masked]
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> > Complex attributes may also be added to the dictionary such 
> that the 
> > RADIUS server does not require code changes to process 
> these attributes.
> 
> This may be true of a class of newer RADIUS server 
> implementations, those with a "dynamic" data dictionary, but 
> it is not true of another class of more "traditional" RADIUS 
> servers, and it's those that this section intends to address.

This would precisely be what one calls an "implementation choice". I'd
again suggest that the Radius WG could do much better then trying to
deal with issues that are actually implementation issues, which does go
to the heart of a lot of the arguments on this thread.

-Woj.

> 
> As I said in a previous post, the plan is to recommend (via 
> this BCP) that newly design RADIUS attributes not contribute 
> to rendering a significant installed base of deployed RADIUS 
> servers effectively obsolete.
> 
> If we were talking about VSAs, this wouldn't be a concern.  
> We're talking about standards-tack attributes.  If all you 
> have to worry about is the class of "enhanced capability" 
> RADIUS servers, then I would agree.  In the IETF, we need to 
> take a broader view, I think.
> 
> To repeat myself (this seems to be in vogue) it's a matter of 
> either revising the protocol or extending the protocol.  
> RADEXT has the charter to do the latter and not the former.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Sun, 17 Jan 2010 20:08:45 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Sun, 17 Jan 2010 15:08:28 -0500

> Complex attributes may also be added to the dictionary such that the
> RADIUS server does not require code changes to process these attributes.

This may be true of a class of newer RADIUS server implementations, those
with a "dynamic" data dictionary, but it is not true of another class of
more "traditional" RADIUS servers, and it's those that this section intends
to address.

As I said in a previous post, the plan is to recommend (via this BCP) that
newly design RADIUS attributes not contribute to rendering a significant
installed base of deployed RADIUS servers effectively obsolete.

If we were talking about VSAs, this wouldn't be a concern.  We're talking
about standards-tack attributes.  If all you have to worry about is the
class of "enhanced capability" RADIUS servers, then I would agree.  In the
IETF, we need to take a broader view, I think.

To repeat myself (this seems to be in vogue) it's a matter of either
revising the protocol or extending the protocol.  RADEXT has the charter to
do the latter and not the former.

Delivery-date: Sun, 17 Jan 2010 19:52:41 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 17 Jan 2010 14:51:38 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

So here is the thread 

Your wrote....
> On 14-01-2010, at 11:16 , Alan DeKok wrote:
>> Your suggestion is *denying* the possibility that RADIUS servers can
>> process complex attributes themselves.  Some people have servers that
>> are capable of encoding and decoding complex types without resorting to
>> adding application layers.

In response I wrote....
> 
> Because according to you, a RADIUS server can be constructed that can encode and decode complex types without resorting to adding application layers and presumably even new code.  The paragraph is thus misleading and should be fixed or removed.

Your response to the above....

 That statement is simply not true under any objective definition of reality.

My response....

(Avi) but Alan I am paraphresing your own statement 

Your response...

>  I don't see how.  I said red, you say blue.  There's a teensy
> difference between the two.

(avi) and now you are saying that that is not what you said???? 

Your response...

> I'm saying your paraphrasing doesn't match my words.  In fact, it's
> nearly the opposite of what I said.

I dont know but I think this accurately reflects the conversation.

In any case.... you continued ....and I want to repsond to you.

> 
> The confusion here seems to be that you appear to believe:
> 
> "complex attributes" == "external application processing of data".

No not at all.   
>  This is not true.

I agree.

>  As my earlier messages said, many implementations
> can process complex data themselves, and don't need external
> applications to do that for them.

Correct.
> 
>  This goes back to the root cause of the disagreement:  The document
> explains one model of RADIUS.  You are arguing that this model is no
> longer applicable.  You want to *require* a newer model.

No the issue is that the document does not explain this model -- and I want it to.  In fact it says the opposite.  And once again I will put in the paragraph that is the offending paragraph....It needs to reflect the statement that complex types can also be handled by these RADIUS server without code change.

   One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes.  RADIUS server implementations
   typically provide support for basic data types, and define attributes
   in a data dictionary.  This architecture enables a new attribute to
   be supported by the addition of a dictionary entry, without requiring
   RADIUS server code changes.

You can simply add something like this to the end of that paragraph:

Complex attributes  may also be added to the dictionary such that the RADIUS server does not require code changes to process these attributes.

Delivery-date: Sun, 17 Jan 2010 13:24:26 +0000
Date: Sun, 17 Jan 2010 14:23:37 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> but Alan I am paraphresing your own statement

  I don't see how.  I said red, you say blue.  There's a teensy
difference between the two.

> and now you are saying that that is not what you said????

  I'm saying your paraphrasing doesn't match my words.  In fact, it's
nearly the opposite of what I said.

  The confusion here seems to be that you appear to believe:

 "complex attributes" = "external application processing of data".

  This is not true.  As my earlier messages said, many implementations
can process complex data themselves, and don't need external
applications to do that for them.

  This goes back to the root cause of the disagreement:  The document
explains one model of RADIUS.  You are arguing that this model is no
longer applicable.  You want to *require* a newer model.

  See Dave Nelsons message for a different response to this request.

  Alan DeKok.

Delivery-date: Sun, 17 Jan 2010 12:00:11 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Sun, 17 Jan 2010 06:59:21 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

Delivery-date: Sun, 17 Jan 2010 10:55:26 +0000
Date: Sun, 17 Jan 2010 11:54:42 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> But you didnt answer the question.

  The question I answered was "why doesn't the section on complex types
have any text about application layers".  My response was direct and to
the point.  *That* point.

  So... you switched the topic to "but complex attributes require code
changes!"  And "But Alan is *denying* they require code changes!"

  It's damning evidence as to how weak your position is.

> In the next paragraph you state "one of the fundamental goals of RADIUS protocol design...."  First what is the purpose of that paragraph - it really makes no recommendations what so ever.

  It explains the rationale behind the recommendations.  And it's
clearly useless, just like most of my responses here.

> Also based on the specific comment in this email dont you think that paragraph is missing some of the information you offer in this email.

  Nope.

> Because according to you, a RADIUS server can be constructed that can encode and decode complex types without resorting to adding application layers and presumably even new code.  The paragraph is thus misleading and should be fixed or removed.

  That statement is simply not true under any objective definition of
reality.

  As before, I refer you to my earlier messages that discuss this exact
topic.

  Alan DeKok.

Delivery-date: Sun, 17 Jan 2010 08:49:19 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 17 Jan 2010 03:48:24 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 16-01-2010, at 10:31 , Alan DeKok wrote:

> Avi Lior wrote:
>> On 14-01-2010, at 11:16 , Alan DeKok wrote:
>>> Your suggestion is *denying* the possibility that RADIUS servers can
>>> process complex attributes themselves.  Some people have servers that
>>> are capable of encoding and decoding complex types without resorting to
>>> adding application layers.
>> 
>> Or new code perhaps.  No?
> 
>  Or "having had your question answered and your point refuted, the only
> possible response is to change the subject".

But you didnt answer the question.  You continue to evade and thus you get asked the same question over and over again.

So again, such server can they handle complex attribute without requiring no code.  Yes or No?

In the document on page 9 (bottom) you are asserting the virtues of taking a complex attribute and using instead standard based attributes.

In the next paragraph you state "one of the fundamental goals of RADIUS protocol design...."  First what is the purpose of that paragraph - it really makes no recommendations what so ever.

Also based on the specific comment in this email dont you think that paragraph is missing some of the information you offer in this email.

Because according to you, a RADIUS server can be constructed that can encode and decode complex types without resorting to adding application layers and presumably even new code.  The paragraph is thus misleading and should be fixed or removed.
--
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/>

Delivery-date: Sat, 16 Jan 2010 15:32:01 +0000
Date: Sat, 16 Jan 2010 16:31:19 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> On 14-01-2010, at 11:16 , Alan DeKok wrote:
>>  Your suggestion is *denying* the possibility that RADIUS servers can
>> process complex attributes themselves.  Some people have servers that
>> are capable of encoding and decoding complex types without resorting to
>> adding application layers.
> 
> Or new code perhaps.  No?

  Or "having had your question answered and your point refuted, the only
possible response is to change the subject".

  As for "new code": asked and answered already.

> I am not denying anything.  I want the document to explain these models.  

  I'm pretty clear on that.

  I'm also clear that every time I point out good reasons why the
document is the way it is... you change the subject to another point
I've already addressed.

  Alan DeKok.

Delivery-date: Sat, 16 Jan 2010 15:29:43 +0000
Date: Sat, 16 Jan 2010 16:28:11 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> I am not expecting you to redefine anything.

  Denial #4 (IIRC)

> You have spent copious amounts of text describing the Data Model.  Why did you do that?

  If it's not clear from the abstract, there's precious little I can say
to help you understand.

> Do the same for the processing model?

  Asked and answered.

  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 21:24:55 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
CC: <[email-masked]>
Subject: RE: Thoughts on Issue 325
Date: Thu, 14 Jan 2010 13:24:15 -0800

Alan said:

"  Pretty much, yes.  Or attributes that encode complex types with
"length" fields that are 16 bits, or are 8-bits of "count of 32-bit
words".  Both can result in the encoded data claiming to be "larger"
than the encapsulating attribute, and lead to overflows."

[BA] Yes, these are the kind of issues that have resulted in widely
publicized exploits against many different RADIUS servers. 

Alan said:

"  I'm not sure we can have an exhaustive checklist.

  Good design is a balance.  Solutions are often a compromise between
two equally ugly alternatives."

[BA] Yes.  However, the question is whether we provide enough info to
enable the reader to understand that balance.  

Alan said:

"  Some of that was due to a desire to be (somewhat) compatible with
existing deployments of an I-D that had not passed review."

[BA] My understanding is that the major change from the draft to
RFC 5090 was chopping up a single string attribute into 20 pieces. 
Some of the individual attributes make sense to me because they
are the kind of thing that might be used in policy logic
(such as the realm).  However, RFC 5090 is about 
authentication, so that the Design Guidelines document would
also appear to offer the possibility to have left the string
intact. 

Overall, RFC 5090 is not viewed very favorably within the
SIP or HTTP communities, and as far as I know, it is much
less widely implemented than the draft which it purported
to "improve".  

So the question in my mind is how this particular case could
should have been handled, and whether that is reflected in
the document. 

Delivery-date: Thu, 14 Jan 2010 18:37:08 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 14 Jan 2010 13:36:18 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

I am not expecting you to redefine anything.

You have spent copious amounts of text describing the Data Model.  Why did you do that?

Do the same for the processing model?

On 14-01-2010, at 11:22 , Alan DeKok wrote:

> Alan DeKok wrote:
>>  The text on page 12 could *perhaps* be clarified by adding:
>> 
>> 	THE TEXT ABOUT APPLICATIONS IS USEFUL IF AND ONLY IF
>> 	YOU HAVE AN APPLICATION THAT SITS ON TOP OF RADIUS.
> 
>  And maybe adding:
> 
> 	BUT WE DON'T WANT TO FALL INTO THE RATS NEST OF DEFINING
> 	EXACTLY WHAT THE DIFFERENCE IS BETWEEN AN APPLICATION LAYER
> 	AND RADIUS.  AFTER ALL, THIS IS A "GUIDELINES" DOCUMENT,
> 	AND NOT A "RE-DEFINE THE ENTIRE RADIUS PROCESSING MODEL"
> 	DOCUMENT.
> 
>  I think that's addressed all of Avi's concerns.
> 
>  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 16:35:08 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 14 Jan 2010 11:34:41 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 14-01-2010, at 11:16 , Alan DeKok wrote:

> Avi Lior wrote:
>> But section 2.1.3 does not reflect that model.  At *that* is the problem.
> 
>  I disagree.
> 
>> As I stated before - on many times - either:
>> 
>> A) Define the Application/RADIUS server model so that it consistently used throughout the document (including secton 2.1.3) or 
>> B) Remove the text about application/RADIUS server on page 12.
>> 
>> What seems to be the problem with that request?
> 
>  Your suggestion is *denying* the possibility that RADIUS servers can
> process complex attributes themselves.  Some people have servers that
> are capable of encoding and decoding complex types without resorting to
> adding application layers.

Or new code perhaps.  No?

I am not denying anything.  I want the document to explain these models.  
> 
>  So there is no need for Section 2.1.3 to discuss application layers.
> 
>  The text on page 12 could *perhaps* be clarified by adding:
> 
> 	THE TEXT ABOUT APPLICATIONS IS USEFUL IF AND ONLY IF
> 	YOU HAVE AN APPLICATION THAT SITS ON TOP OF RADIUS.
> 
>  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 16:23:36 +0000
Date: Thu, 14 Jan 2010 17:22:59 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Alan DeKok wrote:
>   The text on page 12 could *perhaps* be clarified by adding:
> 
> 	THE TEXT ABOUT APPLICATIONS IS USEFUL IF AND ONLY IF
> 	YOU HAVE AN APPLICATION THAT SITS ON TOP OF RADIUS.

  And maybe adding:

	BUT WE DON'T WANT TO FALL INTO THE RATS NEST OF DEFINING
	EXACTLY WHAT THE DIFFERENCE IS BETWEEN AN APPLICATION LAYER
	AND RADIUS.  AFTER ALL, THIS IS A "GUIDELINES" DOCUMENT,
	AND NOT A "RE-DEFINE THE ENTIRE RADIUS PROCESSING MODEL"
	DOCUMENT.

  I think that's addressed all of Avi's concerns.

  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 16:17:31 +0000
Date: Thu, 14 Jan 2010 17:16:28 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> But section 2.1.3 does not reflect that model.  At *that* is the problem.

  I disagree.

> As I stated before - on many times - either:
> 
> A) Define the Application/RADIUS server model so that it consistently used throughout the document (including secton 2.1.3) or 
> B) Remove the text about application/RADIUS server on page 12.
> 
> What seems to be the problem with that request?

  Your suggestion is *denying* the possibility that RADIUS servers can
process complex attributes themselves.  Some people have servers that
are capable of encoding and decoding complex types without resorting to
adding application layers.

  So there is no need for Section 2.1.3 to discuss application layers.

  The text on page 12 could *perhaps* be clarified by adding:

	THE TEXT ABOUT APPLICATIONS IS USEFUL IF AND ONLY IF
	YOU HAVE AN APPLICATION THAT SITS ON TOP OF RADIUS.

  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 15:47:01 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 14 Jan 2010 10:46:34 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

>> 
>> The RADIUS Server layer process the existing attributes types  -- complex attribute intended to be passed through the RADIUS server to the application layer running on-top of the RADIUS server do not require any new code changes in the RADIUS server.
> 
>  The document pretty much says that.  See page 12.
> 
>  It's difficult to make progress when I point out the document already
> says much of what you want, and you deny that outright.
> 

You are missing the point.  I recognize what you are writing on page 12.

But section 2.1.3 does not reflect that model.  At *that* is the problem.

As I stated before - on many times - either:

A) Define the Application/RADIUS server model so that it consistently used throughout the document (including secton 2.1.3) or 
B) Remove the text about application/RADIUS server on page 12.

What seems to be the problem with that request?

Delivery-date: Thu, 14 Jan 2010 15:21:12 +0000
Date: Thu, 14 Jan 2010 16:20:19 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> On 14-01-2010, at 06:11 , Alan DeKok wrote:
> 

  <sigh>

  The miscommunication here is simple.  I explain my position using
simple words, and you tell me I'm not saying what I think I'm saying.

>>> And really what are you writing this BCP for - isnt it to guide new work?  And is this new work guiding to be relevant to the 40% or the 60% of the market space?
>>  Asked and answered.  No amount of repeating the question will change
>> the answer.
> You are right and the rest of us are wrong.

  I'm tilting at windmills.

> The RADIUS server performs these functions  .....
> The Application layer performs these functions ....
> 
> The reader will then understand what is going on.

  I doubt it.

  I have repeatedly explained my position.  You have repeatedly denied
that my direct statements reflect my position.

> The RADIUS Server layer process the existing attributes types  -- complex attribute intended to be passed through the RADIUS server to the application layer running on-top of the RADIUS server do not require any new code changes in the RADIUS server.

  The document pretty much says that.  See page 12.

  It's difficult to make progress when I point out the document already
says much of what you want, and you deny that outright.

  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 14:59:25 +0000
From: Avi Lior <[email-masked]>
To: "Wojciech Dec (wdec)" <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 Jan 2010 09:59:11 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

I absolutely agree. 

Historically, specifically around this document  -- consensus has not been a working group priority.

On 12-01-2010, at 07:41 , Wojciech Dec (wdec) wrote:

> 
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of David B. Nelson
>> Sent: 11 January 2010 21:21
>> To: [email-masked]
>> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
>> 
>> On Jan 11, 2010, at 2:44 PM, Avi Lior wrote:
>> 
>> 
>> I understand, but at some point you may want to consider 
>> simply accepting the WG consensus on this and to find another 
>> way to address your issues.  Attempting to re-open closed 
>> discussions isn't productive
> 
> Woj> Sorry to hark on, but in terms of "consensus" and not re-opening
> closed discussions, judging by the number of folks who have raised the
> issue, it would be better to say that there no longer is consensus, with
> even a rough consensus being questionable. Sometimes one needs to be
> able take a step back inorder to move forward.
> 
> -Woj.
> 
> 
>> 
>>> I can just ignore this document at the IETF but the 
>> problem is that it will  > haunt me at the SDO level.
>> 
>> I'm certainly not suggesting that you (or anyone) ignore the document.
>> 
>>> Several people told me that no one will take this document 
>> seriously  > and that I should let it go.
>> 
>> Well, those who give you that advice would appear to me to 
>> not take the standard process seriously.
>> 
>>> What is the purpose of this document?
>> 
>> The purpose is to document the Internet community's 
>> assessment of the Best Current Practice for designing RADIUS 
>> Attributes for the "traditional" RADIUS protocol, as defined 
>> in RFC 2865.
>> 
>> The purpose of the RADIUS Extended Attributes document is to 
>> address the shortcomings of the "traditional" RADIUS data 
>> model that we are all very familiar with.  Or at least to 
>> partially address those shortcomings.  The WG consensus on 
>> that does stop short of creating full feature-parity with Diameter.
>> 
>> 
>> --
>> to unsubscribe send a message to 
>> [email-masked] with the word 'unsubscribe' in 
>> a single line as the message text body.

Delivery-date: Thu, 14 Jan 2010 14:57:55 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 14 Jan 2010 09:56:55 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 14-01-2010, at 06:11 , Alan DeKok wrote:

> Avi Lior wrote:
>>> 40% (or more) of current RADIUS deployments would disagree.
>> Good so 60% do and I think and other think that you should address the majority cases No?
> 
>  As I have said repeatedly, the document addresses the capabilities of
> 100% of the deployments.

Just  because you say it - whether once or repeatedly - that doesn't make it so.
> 
>> I was requesting that you define the model you are using.
> 
>  The document does.
> 
Again it does not.

>>   From Guidelines "One of the fundamental goals of the RADIUS protocol design was to
>>   allow RADIUS servers to be configured to support new attributes
>>   without requiring server code changes.
>> 
>> I dont understand how adding a new attribute of an existing type to an Access-Request does not require code changes in the RADIUS server?  The RADIUS server has to process this attribute no?  It has to make policy decision based on this attribute no?
> 
>  I have responded to this point many times already.
And we have been questioning your response many times. 

> 
>> Next you talk about the following:
>> 
>> "On the RADIUS client, code changes are typically required in order to
>>   implement a new attribute.  The RADIUS client typically has to
>>   compose the attribute dynamically when sending.  When receiving, a
>>   RADIUS client needs to be able to parse the attribute and carry out
>>   the requested service.  As a result, a detailed understanding of the
>>   new attribute is required on clients, and data dictionaries are less
>>   useful on clients than on servers."
>> 
>> But this confuses me.... I think that Clients and Servers  have to do the same work.  I think that both require a detailed understanding of a new attribute.  
> 
>  See Bernards review for one answer.   See my previous dozen (or so)
> messages for my attitude.
But it requires code change in the server.
> 
>> I do agree that Servers get attributes from a database when composing a response and certainly that is true for older generations of server.  But today and going forward this is not true.
> 
>  Today, this is still true.
Yes but partly whereas in the past it was exclusively true.

> 
>  Your message is blatant in its agenda: "No, I don't want to re-define
> RADIUS.  But no existing RADIUS servers use static attribute definitions".
You know that that is not true.  I never said that RADIUS server never use static attributes defintion.  But statements in your document makes that assertion.  Directly, as in" RADIUS protocol design was allow RADIUS servers to be configured to support new attributes
  without requiring server code changes."
and indirectly "On the RADIUS client, code changes are typically required in order to implement a new attribute"

> 
>> Similarly, in the historic use of RADIUS servers,  we got username password and all we did was look this up in  a database.  Today typically we get service request attributes, we get hints of location etc... the Server has to parse these and understand them.
>> 
>> So I agree the goal was -- but it is no longer relevant in 60% of the cases.
> 
>  So basic username / password authentication is no longer relevant in
> the 60% case?  Is that what you really meant to say?

No and I think you know that. 

> 
>> And really what are you writing this BCP for - isnt it to guide new work?  And is this new work guiding to be relevant to the 40% or the 60% of the market space?
> 
>  Asked and answered.  No amount of repeating the question will change
> the answer.
You are right and the rest of us are wrong.
> 
>> No  I think you are being a little unfair. The main rational is that you are making claims that complex attributes are bad and insecure and you are basing on erroneous model that caters to traditional/old deployments that compose 40% of the market (your number).  This perhaps is where you work.
> 
>  Already answered in previous messages.
> 
>> I think you should cater to or at least recognize the other 60% of the market where this model is not valid anymore.  This is where I work at the SDOs.  
> 
>  ... outright denying my multiple messages that recognize that model.
> 
>> By at least explicitly documenting the model you are using....then we can judge the applicability of this document. Right now it is not obvious.
> 
>  The traditional RADIUS model isn't obvious?
> 
>> As a minimum be explicit about the model you are catering to.
> 
>  ... outright denying that the document contains an explicit
> description of the model.
> 
>> Why my life would difficult at the SDO is that I would have to explain this to folks and I'd rather the document explain the model being used.  Then SDOs will understand that this document does not apply to them since mostly they require that the Server interact with the attributes it receives and sends rather then just look stuff up in the database.
> 
>  And that's the real discussion.  You object to a document which says
> "complex attributes are allowed, but simpler ones are preferred."  You
> object because people will point to it, and wonder why your design
> contains unnecessarily complex attributes.
> 
>> I cant to this because i never claimed that attribute design guidelines dont belong here.  I perhaps said that if you dont want to fix the problems then just take the stuff out.
> 
>  "stuff" meaning "attribute design guidelines for complex data".
> 
>>> The closest you've come to this is saying that text about the
>>> application layer doesn't belong in the document.  That's a good
>>> argument, but there are arguments to counter it, too.
>> 
>> I didnt really say that either. I wanted you to add discussion on application layer and RADIUS layer.  You didnt want to.
> 
>  The document already has text on that topic.
> 
>> See, the document recogonizes that there is some application layer stuff happening on the client (NAS).  It totally ignores that there are application layer stuff happening on the Server.  That is the root problem in the document - for me.
> 
>  ... outright denying the text on page 12 which discusses applications
> using data supplied by the server.

I see that and I am simply askig that you define that model so that when I read the following text:

 One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes.  

What I am asking for is to explain that the RADIUS on the server side consists of a RADIUS Server and an Application Layer

The RADIUS server performs these functions  .....
The Application layer performs these functions ....

The reader will then understand what is going on.

The RADIUS Server layer process the existing attributes types  -- complex attribute intended to be passed through the RADIUS server to the application layer running on-top of the RADIUS server do not require any new code changes in the RADIUS server.

> 
> 
>  I think this message really clarifies your position for me.  The
> majority of it is outright denial of the document, and of multiple
> explanations of my position.  The rest is, well... not much better.
> 
>  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 12:50:51 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Thu, 14 Jan 2010 07:50:13 -0500

I haven't heard anyone disagree that the market demands more of RADIUS today
than it did when RADIUS was devised.

What's in contention is *how* to address the evolving market requirements.
In the IETF tradition there are three approaches to address the need for
added functionality in a legacy protocol:

(1) Write a new protocol to replace the old one.

(2) Extend the old protocol, using suitable extension mechanisms that permit
backward-forward compatibility and that don't effectively obsolete the older
implementations.

(3) Revise the old protocol by issuing a new version, e.g. V2, using a
suitable version numbering and version negotiation mechanism, so that older
implementations can interoperate with newer implementation when only the
legacy functionality is required.

I've heard a fourth method suggested in this discussion:

(4) Revise the old protocol by adding new functionality, without regard to
whether it effectively obsoletes legacy implementations.

I think it's this fourth approach that Alan finds unacceptable.  I tend to
agree that it's not the IETF way, and it's basically unfair to a large
constituency of implementers.

The AAA WG was chartered to work on either approach (1) or (3).  They
considered a RADIUS V2 proposal (approach (3)) and decided against that in
favor of Diameter (approach (1)).

The RADEXT WG was chartered to work on approach (2).  I think we need to
assiduously avoid wandering into approach (4).

Delivery-date: Thu, 14 Jan 2010 11:12:00 +0000
Date: Thu, 14 Jan 2010 12:11:19 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
>>  40% (or more) of current RADIUS deployments would disagree.
> Good so 60% do and I think and other think that you should address the majority cases No?

  As I have said repeatedly, the document addresses the capabilities of
100% of the deployments.

> I was requesting that you define the model you are using.

  The document does.

>    From Guidelines "One of the fundamental goals of the RADIUS protocol design was to
>    allow RADIUS servers to be configured to support new attributes
>    without requiring server code changes.
> 
> I dont understand how adding a new attribute of an existing type to an Access-Request does not require code changes in the RADIUS server?  The RADIUS server has to process this attribute no?  It has to make policy decision based on this attribute no?

  I have responded to this point many times already.

> Next you talk about the following:
> 
> "On the RADIUS client, code changes are typically required in order to
>    implement a new attribute.  The RADIUS client typically has to
>    compose the attribute dynamically when sending.  When receiving, a
>    RADIUS client needs to be able to parse the attribute and carry out
>    the requested service.  As a result, a detailed understanding of the
>    new attribute is required on clients, and data dictionaries are less
>    useful on clients than on servers."
> 
> But this confuses me.... I think that Clients and Servers  have to do the same work.  I think that both require a detailed understanding of a new attribute.  

  See Bernards review for one answer.   See my previous dozen (or so)
messages for my attitude.

> I do agree that Servers get attributes from a database when composing a response and certainly that is true for older generations of server.  But today and going forward this is not true.

  Today, this is still true.

  Your message is blatant in its agenda: "No, I don't want to re-define
RADIUS.  But no existing RADIUS servers use static attribute definitions".

  No, no contradiction there.

>  More often now servers have to compose their response by computing the attributes dynamically.

  Does a "memcpy" count?

> Similarly, in the historic use of RADIUS servers,  we got username password and all we did was look this up in  a database.  Today typically we get service request attributes, we get hints of location etc... the Server has to parse these and understand them.
> 
> So I agree the goal was -- but it is no longer relevant in 60% of the cases.

  So basic username / password authentication is no longer relevant in
the 60% case?  Is that what you really meant to say?

>  And really what are you writing this BCP for - isnt it to guide new work?  And is this new work guiding to be relevant to the 40% or the 60% of the market space?

  Asked and answered.  No amount of repeating the question will change
the answer.

> No  I think you are being a little unfair. The main rational is that you are making claims that complex attributes are bad and insecure and you are basing on erroneous model that caters to traditional/old deployments that compose 40% of the market (your number).  This perhaps is where you work.

  Already answered in previous messages.

> I think you should cater to or at least recognize the other 60% of the market where this model is not valid anymore.  This is where I work at the SDOs.  

  ... outright denying my multiple messages that recognize that model.

> By at least explicitly documenting the model you are using....then we can judge the applicability of this document. Right now it is not obvious.

  The traditional RADIUS model isn't obvious?

> As a minimum be explicit about the model you are catering to.

  ... outright denying that the document contains an explicit
description of the model.

> Why my life would difficult at the SDO is that I would have to explain this to folks and I'd rather the document explain the model being used.  Then SDOs will understand that this document does not apply to them since mostly they require that the Server interact with the attributes it receives and sends rather then just look stuff up in the database.

  And that's the real discussion.  You object to a document which says
"complex attributes are allowed, but simpler ones are preferred."  You
object because people will point to it, and wonder why your design
contains unnecessarily complex attributes.

> I cant to this because i never claimed that attribute design guidelines dont belong here.  I perhaps said that if you dont want to fix the problems then just take the stuff out.

  "stuff" meaning "attribute design guidelines for complex data".

>>  The closest you've come to this is saying that text about the
>> application layer doesn't belong in the document.  That's a good
>> argument, but there are arguments to counter it, too.
> 
> I didnt really say that either. I wanted you to add discussion on application layer and RADIUS layer.  You didnt want to.

  The document already has text on that topic.

> See, the document recogonizes that there is some application layer stuff happening on the client (NAS).  It totally ignores that there are application layer stuff happening on the Server.  That is the root problem in the document - for me.

  ... outright denying the text on page 12 which discusses applications
using data supplied by the server.

  I think this message really clarifies your position for me.  The
majority of it is outright denial of the document, and of multiple
explanations of my position.  The rest is, well... not much better.

  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 10:50:23 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 14 Jan 2010 05:49:40 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

>> 
>> And even in the extended document i did not want to extend the attribute in the sense of COmplex Types.  The working group did.  All we were trying to do is extended the attribute type space beyond 256.
> 
>  ... and add a new grouping mechanism
> 
>  ... and add a mechanism to allow attributes longer than 253 octets.
> 
> http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-02.txt
> 
>  That's from 2007, before it was a WG draft.  I can read, too.

So draft http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-00.txt
dated Nov 25, 2003  Did not have tagging or anyting like that.  That was document laid dormanent until October 19, 2006
when http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-01.txt came out with tagging added.

This if you can recall was because of all sudden the group decided that they wanted this work and they asked us to extended with grouping. This is when Glen was added and he became the editor adding stuff that the WG asked for.

You maybe capable of reading but that isn't enough I am afraid.  You should know the history around this document. 

> 
> Avi Lior, January 6:
>>>> I think it would be worth while to define the RADIUS model first.
>>>> Not the old RADIUS model but rather the one that we are all living
>>>> with today.  That model is not really different then Diameter.
> 
>  40% (or more) of current RADIUS deployments would disagree.
Good so 60% do and I think and other think that you should address the majority cases No?

On 14-01-2010, at 02:50 , Alan DeKok wrote:

> Avi Lior wrote:
>> I am not proposing to redefine RADIUS. Please show me where I am doing that WRT to this document.
> 
>  You are *demanding* that the traditional RADIUS model be removed from
> the document.  You have stated that it is no longer relevant:

Never!!!!  I was requesting that you define the model you are using. And because the document does talk about applications.  Just define it.  At the root of this is the following statement:

   From Guidelines "One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes.

I dont understand how adding a new attribute of an existing type to an Access-Request does not require code changes in the RADIUS server?  The RADIUS server has to process this attribute no?  It has to make policy decision based on this attribute no?

Next you talk about the following:

"On the RADIUS client, code changes are typically required in order to
   implement a new attribute.  The RADIUS client typically has to
   compose the attribute dynamically when sending.  When receiving, a
   RADIUS client needs to be able to parse the attribute and carry out
   the requested service.  As a result, a detailed understanding of the
   new attribute is required on clients, and data dictionaries are less
   useful on clients than on servers."

But this confuses me.... I think that Clients and Servers  have to do the same work.  I think that both require a detailed understanding of a new attribute.  

I do agree that Servers get attributes from a database when composing a response and certainly that is true for older generations of server.  But today and going forward this is not true.  More often now servers have to compose their response by computing the attributes dynamically.

Similarly, in the historic use of RADIUS servers,  we got username password and all we did was look this up in  a database.  Today typically we get service request attributes, we get hints of location etc... the Server has to parse these and understand them.

So I agree the goal was -- but it is no longer relevant in 60% of the cases.  And really what are you writing this BCP for - isnt it to guide new work?  And is this new work guiding to be relevant to the 40% or the 60% of the market space?

I have been asking RADEXT to consider this.

> 
>> Take a look at my comments and comments made by other folks and stick to those topics.  That is if you want to make progress.
> 
>  I have seen *no* relevant argument for removing discussions on
> attribute design from the design guidelines document.  The main
> rationale put forward is "it will make my life difficult in an SDO".
> (Which also puts paid to the argument that "everyone will ignore it")

No  I think you are being a little unfair. The main rational is that you are making claims that complex attributes are bad and insecure and you are basing on erroneous model that caters to traditional/old deployments that compose 40% of the market (your number).  This perhaps is where you work.

I think you should cater to or at least recognize the other 60% of the market where this model is not valid anymore.  This is where I work at the SDOs.  

By at least explicitly documenting the model you are using....then we can judge the applicability of this document. Right now it is not obvious.

As a minimum be explicit about the model you are catering to.

Why my life would difficult at the SDO is that I would have to explain this to folks and I'd rather the document explain the model being used.  Then SDOs will understand that this document does not apply to them since mostly they require that the Server interact with the attributes it receives and sends rather then just look stuff up in the database.

> 
>  The issue is *not* about "complex types", though that is the main
> point of contention.  It's whether or not attribute design guidelines
> belong in the design guidelines document.
> 
>  Please explain in short, simple words why design guidelines do not
> belong in the design guidelines document.  Don't mention "complex
> types".  Don't mention "traditional" versus "modern" RADIUS model.

I cant to this because i never claimed that attribute design guidelines dont belong here.  I perhaps said that if you dont want to fix the problems then just take the stuff out.

> 
>  The closest you've come to this is saying that text about the
> application layer doesn't belong in the document.  That's a good
> argument, but there are arguments to counter it, too.

I didnt really say that either. I wanted you to add discussion on application layer and RADIUS layer.  You didnt want to.

See, the document recogonizes that there is some application layer stuff happening on the client (NAS).  It totally ignores that there are application layer stuff happening on the Server.  That is the root problem in the document - for me.

There are other issues.

>  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 08:12:22 +0000
Date: Thu, 14 Jan 2010 09:11:57 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Thoughts on Issue 325

Bernard Aboba wrote:
> In Issue 325 (see
> a.       *Clearer articulation of the current situation.*    As noted in
> Joe’s original posting, not all uses of complex attributes (such as
> sending of a complex attribute from server to client) require code
> changes on the server, and the need for code changes
> differ considering whether we are talking about the client or server
> side, or whether the attribute is being sent or received.

  I will see if I can propose some text.

> b.      *More detailed look at security issues.*  Section 2.1.4
> addresses the potential security vulnerabilities of complex attributes. 
> However, since RADIUS has been around a while, we have concrete data
> relating to the types of issues that tend to result
> in major security problems

  Have all of the vendors published all vulnerabilities?

  We are only seeing a portion of the issues in any vulnerability database.

  My experience has been:

a) most externally exploitable crashes / overflows are due to
encoding/decoding of packet data.  Since the RADIUS packet format hasn't
changed in 15 years, the culprit to blame is attributes.  Since the
encoding/decoding of int/ipaddr/etc. (simple) attributes hasn't changed
in 15 years. the culprit to blame is text/string attributes.

b) many other vulnerabilities are due to insecure *use* of packet data.
 These issues don't usually apply to int/ipaddr/etc (simple) attributes,
as it is difficult to send malicious data in them.  The issues usually
have to do with text/string attributes.  (i.e. complex ones)

c) I've managed to crash a number of systems doing interoperabilty
tests.  To my recollection, many of these issues were never publicly
reported in a vulnerability database.

> Looking
> at the past incidents, it is not clear to me that all “complex”
> attributes would be equally likely to exhibit these problems.
> 
> For example, it would seem to me that a “complex” attribute of fixed
> length would be less likely to be vulnerable to a buffer
> overflow than one that involved variable length, particularly if this
> was combined with polymorphism and/or nesting.

  Pretty much, yes.  Or attributes that encode complex types with
"length" fields that are 16 bits, or are 8-bits of "count of 32-bit
words".  Both can result in the encoded data claiming to be "larger"
than the encapsulating attribute, and lead to overflows.

> c.       *Additional considerations.*  As noted in the Appendix,
>  complex RADIUS attributes have been used in the past, so
> that in those cases their merit was thought to outweigh the
> disadvantages.   While A 2.2 does provide considerations
> useful for the evaluation of a “complex” attribute design, it is not
> clear to me that all the useful elements of a potential
> checklist have been taken into account.

  I'm not sure we can have an exhaustive checklist.

  Good design is a balance.  Solutions are often a compromise between
two equally ugly alternatives.

>  For example, looking back at
> RFC 5090,  the decision was made to break up
> a “complex” String attribute into 20 separate attributes.    Given the
> number of additional attributes that were
> consumed as well as the effort required to parse each of these 20
> attributes,  did this decision really generate
> benefits in excess of the costs?   In retrospect, the argument does not
> seem like a slam dunk.

  Some of that was due to a desire to be (somewhat) compatible with
existing deployments of an I-D that had not passed review.

  Alan DeKok.

Delivery-date: Thu, 14 Jan 2010 07:51:28 +0000
Date: Thu, 14 Jan 2010 08:50:25 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> I am not proposing to redefine RADIUS. Please show me where I am doing that WRT to this document.

  You are *demanding* that the traditional RADIUS model be removed from
the document.  You have stated that it is no longer relevant:

Avi Lior, January 6:
>>> I think it would be worth while to define the RADIUS model first.
>>> Not the old RADIUS model but rather the one that we are all living
>>> with today.  That model is not really different then Diameter.

  40% (or more) of current RADIUS deployments would disagree.

  There is *no question* you are trying to redefine RADIUS.  There is no
question that you want to require it be more than the traditional model.

> And even in the extended document i did not want to extend the attribute in the sense of COmplex Types.  The working group did.  All we were trying to do is extended the attribute type space beyond 256.

  ... and add a new grouping mechanism

  ... and add a mechanism to allow attributes longer than 253 octets.

http://tools.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-02.txt

  That's from 2007, before it was a WG draft.  I can read, too.

> Take a look at my comments and comments made by other folks and stick to those topics.  That is if you want to make progress.

  I have seen *no* relevant argument for removing discussions on
attribute design from the design guidelines document.  The main
rationale put forward is "it will make my life difficult in an SDO".
(Which also puts paid to the argument that "everyone will ignore it")

  The issue is *not* about "complex types", though that is the main
point of contention.  It's whether or not attribute design guidelines
belong in the design guidelines document.

  Please explain in short, simple words why design guidelines do not
belong in the design guidelines document.  Don't mention "complex
types".  Don't mention "traditional" versus "modern" RADIUS model.

  The closest you've come to this is saying that text about the
application layer doesn't belong in the document.  That's a good
argument, but there are arguments to counter it, too.

  Alan DeKok.

Delivery-date: Wed, 13 Jan 2010 22:28:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: Thoughts on Issue 325
Date: Wed, 13 Jan 2010 14:27:18 -0800

------=_NextPart_000_03CE_01CA945C.83285100
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In Issue 325 (see
http://aboba.drizzlehosting.com/RADEXT/radissues3.html#Issue%20325) ,  Joe
pointed out a number of

issues within the Design Guidelines document Sections 2.1.3, 2.1.4, 5, A2.1
and A2.2.  

The comments on Sections 5 and A.2.1 relate to the clarity of those
sections, which presumably can be addressed by appropriate edits, 

so I will not dwell on those aspects. 

Instead I will focus on the comments on Sections 2.1.3, 2.1.4 and A 2.2,
which relate to  complex attributes.   Those Sections

have garnered considerable discussion on the list, much of it "frank" (to
use a diplomatic phrase). 

With respect to complex attributes, my interpretation of the list discussion
is that Sections 2.1.3, 2.1.4 and A 2.2 should be revised.   

IMHO, improvements could be made in some of the following aspects of the
current text: 

a.       Clearer articulation of the current situation.    As noted in Joe's
original posting, not all uses of complex attributes (such as

sending of a complex attribute from server to client) require code changes
on the server, and the need for code changes

differ considering whether we are talking about the client or server side,
or whether the attribute is being sent or received. 

My personal take is that Section 2.1.3 could do with some restructuring to
better articulate the implications of each scenario (see

http://ops.ietf.org/lists/radiusext/2009/msg00665.html for details). 

b.      More detailed look at security issues.  Section 2.1.4 addresses the
potential security vulnerabilities of complex attributes.  

However, since RADIUS has been around a while, we have concrete data
relating to the types of issues that tend to result 

in major security problems (e.g. see
http://securityvulns.com/advisories/radius.asp ), such as buffer overflows.
Looking

at the past incidents, it is not clear to me that all "complex" attributes
would be equally likely to exhibit these problems.

For example, it would seem to me that a "complex" attribute of fixed length
would be less likely to be vulnerable to a buffer

overflow than one that involved variable length, particularly if this was
combined with polymorphism and/or nesting. 

c.       Additional considerations.  As noted in the Appendix,  complex
RADIUS attributes have been used in the past, so

that in those cases their merit was thought to outweigh the disadvantages.
While A 2.2 does provide considerations

useful for the evaluation of a "complex" attribute design, it is not clear
to me that all the useful elements of a potential 

checklist have been taken into account.  For example, looking back at RFC
5090,  the decision was made to break up 

a "complex" String attribute into 20 separate attributes.    Given the
number of additional attributes that were 

consumed as well as the effort required to parse each of these 20
attributes,  did this decision really generate

benefits in excess of the costs?   In retrospect, the argument does not seem
like a slam dunk. 

------=_NextPart_000_03CE_01CA945C.83285100
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:851067218;
	mso-list-type:hybrid;
	mso-list-template-ids:-310626080 67698713 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal>In Issue 325 (see http://aboba.drizzlehosting.com/RADEXT/radissues3.html#Issue%20325)
, &nbsp;Joe pointed out a number of<o:p></o:p></p>

<p class=MsoNormal>issues within the Design Guidelines document Sections 2.1.3,
2.1.4, 5, A2.1 and A2.2. &nbsp;<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>The comments on Sections 5 and A.2.1 relate to the clarity
of those sections, which presumably can be addressed by appropriate edits, <o:p></o:p></p>

<p class=MsoNormal>so I will not dwell on those aspects. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Instead I will focus on the comments on Sections 2.1.3,
2.1.4 and A 2.2, which relate to &nbsp;complex attributes.&nbsp;&nbsp; Those
Sections<o:p></o:p></p>

<p class=MsoNormal>have garnered considerable discussion on the list, much of
it &#8220;frank&#8221; (to use a diplomatic phrase). <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>With respect to complex attributes, my interpretation of the
list discussion is that Sections 2.1.3, 2.1.4 and A 2.2 should be revised.&nbsp;&nbsp;
<o:p></o:p></p>

<p class=MsoNormal>IMHO, improvements could be made in some of the following
aspects of the current text: <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>a.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><b>Clearer articulation of the current situation.</b>&nbsp;
&nbsp;&nbsp;As noted in Joe&#8217;s original posting, not all uses of complex
attributes (such as<o:p></o:p></p>

<p class=MsoListParagraph>sending of a complex attribute from server to client)
require code changes on the server, and the need for code changes<o:p></o:p></p>

<p class=MsoListParagraph>differ considering whether we are talking about the
client or server side, or whether the attribute is being sent or received. <o:p></o:p></p>

<p class=MsoListParagraph>My personal take is that Section 2.1.3 could do with
some restructuring to better articulate the implications of each scenario (see<o:p></o:p></p>

<p class=MsoListParagraph><a
href="http://ops.ietf.org/lists/radiusext/2009/msg00665.html">http://ops.ietf.org/lists/radiusext/2009/msg00665.html</a>
for details). <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>b.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><b>More detailed look at security issues.</b>&nbsp;
Section 2.1.4 addresses the potential security vulnerabilities of complex attributes.&nbsp;
<o:p></o:p></p>

<p class=MsoListParagraph>However, since RADIUS has been around a while, we
have concrete data relating to the types of issues that tend to result <o:p></o:p></p>

<p class=MsoListParagraph>in major security problems (e.g. see &nbsp;<a
href="http://securityvulns.com/advisories/radius.asp">http://securityvulns.com/advisories/radius.asp</a>
), such as buffer overflows.&nbsp;&nbsp; &nbsp;Looking<o:p></o:p></p>

<p class=MsoListParagraph>at the past incidents, it is not clear to me that all
&#8220;complex&#8221; attributes would be equally likely to exhibit these
problems.<o:p></o:p></p>

<p class=MsoListParagraph>For example, it would seem to me that a &#8220;complex&#8221;
attribute of fixed length would be less likely to be vulnerable to a buffer<o:p></o:p></p>

<p class=MsoListParagraph>overflow than one that involved variable length,
particularly if this was combined with polymorphism and/or nesting. <o:p></o:p></p>

<p class=MsoListParagraph><o:p>&nbsp;</o:p></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='mso-list:Ignore'>c.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><b>Additional considerations.</b>&nbsp; As noted in the
Appendix, &nbsp;complex RADIUS attributes have been used in the past, so<o:p></o:p></p>

<p class=MsoListParagraph>that in those cases their merit was thought to
outweigh the disadvantages.&nbsp; &nbsp;While A 2.2 does provide considerations<o:p></o:p></p>

<p class=MsoListParagraph>useful for the evaluation of a &#8220;complex&#8221;
attribute design, it is not clear to me that all the useful elements of a
potential <o:p></o:p></p>

<p class=MsoListParagraph>checklist have been taken into account.&nbsp; For
example, looking back at RFC 5090, &nbsp;the decision was made to break up <o:p></o:p></p>

<p class=MsoListParagraph>a &#8220;complex&#8221; String attribute into 20
separate attributes.&nbsp;&nbsp; &nbsp;Given the number of additional
attributes that were <o:p></o:p></p>

<p class=MsoListParagraph>consumed as well as the effort required to parse each
of these 20 attributes, &nbsp;did this decision really generate<o:p></o:p></p>

<p class=MsoListParagraph>benefits in excess of the costs?&nbsp;&nbsp; In
retrospect, the argument does not seem like a slam dunk. <o:p></o:p></p>

<p class=MsoListParagraph><o:p>&nbsp;</o:p></p>

<p class=MsoListParagraph><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_03CE_01CA945C.83285100--

Delivery-date: Wed, 13 Jan 2010 15:18:26 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: External review of the "Status Server" document
Date: Wed, 13 Jan 2010 07:18:06 -0800

--_52ce3a1a-7fb6-4814-be9a-5a329be6540f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT WG last call has concluded on the "Status Server" document.  No comments were received. 

Prior to sending this document on to the IESG for publication as an Informational RFC, we would like the document to be reviewed by someone familiar with existing Status Server implementations (such as the original implementation by Ascend) so as to ensure that the document accurately describes running code. 

If you have knowledge of one or more existing Status Server implementations, please look at the document and post your comments to the RADEXT WG mailing list ([email-masked]).  The document is available for inspection here:
http://tools.ietf.org/html/draft-ietf-radext-status-server

--_52ce3a1a-7fb6-4814-be9a-5a329be6540f_
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:Verdana
}
--></style>
</head>
<body class='hmmessage'>
RADEXT WG last call has concluded on the "Status Server" document.&nbsp; No comments were received. <br>
<br>
Prior to sending this document on to the IESG for publication as an Informational RFC, we would like the document to be reviewed by someone familiar with existing Status Server implementations (such as the original implementation by Ascend) so as to ensure that the document accurately describes running code. <br><br>If you have knowledge of one or more existing Status Server implementations, please look at the document and post your comments to the RADEXT WG mailing list ([email-masked]).&nbsp; The document is available for inspection here:<br>http://tools.ietf.org/html/draft-ietf-radext-status-server<br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>
--_52ce3a1a-7fb6-4814-be9a-5a329be6540f_--

Delivery-date: Wed, 13 Jan 2010 15:13:31 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Transport Directorate review of "RADIUS over TCP" document
Date: Wed, 13 Jan 2010 07:12:32 -0800

--_cda904b7-3f7e-493f-8340-cc377f5c7ee8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT WG last call has concluded on the "RADIUS over TCP" document.  No comments were received. 

Prior to sending this document on to the IESG for publication as an Experimental RFC, review by the Transport Directorate has been requested.   The TSV-DIR review (when completed), will be posted to the RADEXT WG mailing list. 

--_cda904b7-3f7e-493f-8340-cc377f5c7ee8_
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:Verdana
}
--></style>
</head>
<body class='hmmessage'>
RADEXT WG last call has concluded on the "RADIUS over TCP" document.&nbsp; No comments were received. <br><br>Prior to sending this document on to the IESG for publication as an Experimental RFC, review by the Transport Directorate has been requested.&nbsp;&nbsp; The TSV-DIR review (when completed), will be posted to the RADEXT WG mailing list. <br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>
--_cda904b7-3f7e-493f-8340-cc377f5c7ee8_--

Delivery-date: Tue, 12 Jan 2010 17:54:41 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 12 Jan 2010 12:54:03 -0500

On Jan 12, 2010, at 11:44 AM, Avi Lior wrote:

> That is a separate argument - different discussion - different  
> draft.  I am not trying to bring in Complex types in this document.

I'm sorry, I obviously misunderstood your comments.  I was sure that  
one of your comments pertained to the section of the draft covered  
this issue.  I'll go back and re-read some of the earlier posts in  
this thread.

Delivery-date: Tue, 12 Jan 2010 16:50:38 +0000
From: Avi Lior <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 12 Jan 2010 11:50:18 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

> Well, I suspect that many of these non-IETF SDOs that undertake such usage
> do so largely because of your efforts.

Just for the record, some of those SDOs did what they did before my arrival on the scene.  So I dont want to take the credit.

And the IETF has been using String attributes to make complex attributes before my time at the IETF. 

I think you were invovled with RADIUS before me - That is an observation.  I will let you draw your own conclusions on the implications of that observation.

Delivery-date: Tue, 12 Jan 2010 16:45:26 +0000
From: Avi Lior <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 12 Jan 2010 11:44:48 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 12-01-2010, at 11:07 , David B. Nelson wrote:

> On Jan 12, 2010, at 10:14 AM, Avi Lior wrote:
> 
>> I am sorry but i dont understand the concept of a non-IETF SDO vs (I  
>> assume) an IETF SDO.
> 
> The is no significant concept there other than the fact that I  
> consider the IETF to be an SDO.
> 
>> I think that that is a personal attack David...
> 
> It was not intended as an attack, but simply as an observation.

I am pretty sure that this response proves something --- I will let the others deal with this in appropriateness. 

> 
>> You have no idea what I have been doing in other SDOs.
> 
> With all due respect, you personally told me as much during one of the  
> IETF social events.  Do you recall?  While I do see an element of  
> irony here, let's not get diverted down that "rathole".

I told you many things in social events.  I don't recall ever telling you that I undermine the IETF or intent to undermine the IETF.  But since you have justification for your accusation (OBSERVATION) care to share?

> 
> I think the main issue of contention is how to reasonably extend the  
> RADIUS protocol to me the need to advanced applications.  I think that  
> it's reasonable to *extended* RADIUS in a forward / backward  
> compatible way.  What I think is unreasonable is to *re-define* RADIUS  
> in a fashion that "breaks" a large number of fielded deployments.

I am not proposing to redefine RADIUS. Please show me where I am doing that WRT to this document.

>  We  
> can argue all day about whether the "traditional" RADIUS Attributes  
> and data model as defined in RFC encompasses the notion of complex  
> attributes.  What I think is compelling is the fact that a large  
> number of existing implementations took the interpretation that it  
> doesn't.
Are you saying that using a String attribute to carry more then one information element is NOT a complex type.  

> 
> Why is it so onerous to utilize the RADIUS Extended Attribute as the  
> vehicle to address the needs fro complex types and other advanced  
> features?  I simply don't understand.

That is a separate argument - different discussion - different draft.  I am not trying to bring in Complex types in this document.

And even in the extended document i did not want to extend the attribute in the sense of COmplex Types.  The working group did.  All we were trying to do is extended the attribute type space beyond 256.

I am not really sure what you are talking about.

Take a look at my comments and comments made by other folks and stick to those topics.  That is if you want to make progress.

Avi

Delivery-date: Tue, 12 Jan 2010 16:08:16 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 12 Jan 2010 11:07:31 -0500

On Jan 12, 2010, at 10:14 AM, Avi Lior wrote:

> I am sorry but i dont understand the concept of a non-IETF SDO vs (I  
> assume) an IETF SDO.

The is no significant concept there other than the fact that I  
consider the IETF to be an SDO.

> I think that that is a personal attack David...

It was not intended as an attack, but simply as an observation.

> You have no idea what I have been doing in other SDOs.

With all due respect, you personally told me as much during one of the  
IETF social events.  Do you recall?  While I do see an element of  
irony here, let's not get diverted down that "rathole".

I think the main issue of contention is how to reasonably extend the  
RADIUS protocol to me the need to advanced applications.  I think that  
it's reasonable to *extended* RADIUS in a forward / backward  
compatible way.  What I think is unreasonable is to *re-define* RADIUS  
in a fashion that "breaks" a large number of fielded deployments.  We  
can argue all day about whether the "traditional" RADIUS Attributes  
and data model as defined in RFC encompasses the notion of complex  
attributes.  What I think is compelling is the fact that a large  
number of existing implementations took the interpretation that it  
doesn't.

Why is it so onerous to utilize the RADIUS Extended Attribute as the  
vehicle to address the needs fro complex types and other advanced  
features?  I simply don't understand.

Delivery-date: Tue, 12 Jan 2010 15:14:49 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Tue, 12 Jan 2010 10:14:06 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

Please see inline...
On 12-01-2010, at 07:57 , Dave Nelson wrote:

> Avi Lior writes...
> 
>> In essence the document is talking about how bad Complex Types are.
> 
> "Bad" is a loaded, pejorative word.  The document doesn't use it.  The
> document explains why complex types are inappropriate, in most cases, for
> use in "traditional" RADIUS attributes.  The logic is sound, even if you
> personally reject it.

If you really really want to get on with it then you dont need to make comments about my use of the word "Bad".

> 
>> The reality is that every SDO uses them and will continue to use
>> them - because they solve real world problems.
> 
> Well, I suspect that many of these non-IETF SDOs that undertake such usage
> do so largely because of your efforts.

I am sorry but i dont understand the concept of a non-IETF SDO vs (I assume) an IETF SDO.  If there is such a concept then we better explain it in the document.  And for that matter we should define what we mean by an SDO.

>  You are not bound by IETF consensus
> any more than the rest of us.  However, I personally find the extent to
> which you have used your participation in other SDOs as a platform to
> undermine the IETF work a bit disappointing.

I think that that is a personal attack David -- I dont think its appropriate for a chair of an IETF wg to make such comments.

You have no idea what I have been doing in other SDOs.

> 
>> Fix this document.
> 
> The document is not broken.  The IETF consensus position is that complex
> types and other "advanced" RADIUS features belong in the RADIUS Extended
> Attribute format and not in the "traditional" attribute format.  That's not
> an unreasonable position, as it protects the interests of both legacy and
> advanced RADIUS servers.
> 
> 
> 
> --

Delivery-date: Tue, 12 Jan 2010 12:57:41 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 12 Jan 2010 07:57:25 -0500

Avi Lior writes...

> In essence the document is talking about how bad Complex Types are.

"Bad" is a loaded, pejorative word.  The document doesn't use it.  The
document explains why complex types are inappropriate, in most cases, for
use in "traditional" RADIUS attributes.  The logic is sound, even if you
personally reject it.
 
> The reality is that every SDO uses them and will continue to use
> them - because they solve real world problems.

Well, I suspect that many of these non-IETF SDOs that undertake such usage
do so largely because of your efforts.  You are not bound by IETF consensus
any more than the rest of us.  However, I personally find the extent to
which you have used your participation in other SDOs as a platform to
undermine the IETF work a bit disappointing.

> Fix this document.

The document is not broken.  The IETF consensus position is that complex
types and other "advanced" RADIUS features belong in the RADIUS Extended
Attribute format and not in the "traditional" attribute format.  That's not
an unreasonable position, as it protects the interests of both legacy and
advanced RADIUS servers.

Delivery-date: Tue, 12 Jan 2010 12:41:56 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 12 Jan 2010 13:41:30 +0100
From: "Wojciech Dec (wdec)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: 11 January 2010 21:21
> To: [email-masked]
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> On Jan 11, 2010, at 2:44 PM, Avi Lior wrote:
> 
> 
> I understand, but at some point you may want to consider 
> simply accepting the WG consensus on this and to find another 
> way to address your issues.  Attempting to re-open closed 
> discussions isn't productive

Woj> Sorry to hark on, but in terms of "consensus" and not re-opening
closed discussions, judging by the number of folks who have raised the
issue, it would be better to say that there no longer is consensus, with
even a rough consensus being questionable. Sometimes one needs to be
able take a step back inorder to move forward.

-Woj.

> 
>  > I can just ignore this document at the IETF but the 
> problem is that it will  > haunt me at the SDO level.
> 
> I'm certainly not suggesting that you (or anyone) ignore the document.
> 
>  > Several people told me that no one will take this document 
> seriously  > and that I should let it go.
> 
> Well, those who give you that advice would appear to me to 
> not take the standard process seriously.
> 
>  > What is the purpose of this document?
> 
> The purpose is to document the Internet community's 
> assessment of the Best Current Practice for designing RADIUS 
> Attributes for the "traditional" RADIUS protocol, as defined 
> in RFC 2865.
> 
> The purpose of the RADIUS Extended Attributes document is to 
> address the shortcomings of the "traditional" RADIUS data 
> model that we are all very familiar with.  Or at least to 
> partially address those shortcomings.  The WG consensus on 
> that does stop short of creating full feature-parity with Diameter.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Tue, 12 Jan 2010 12:39:36 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "David B. Nelson" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 12 Jan 2010 07:38:37 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

Okay then the target is SDOs.

Then fix the messaging...
In essence the document is talking about how bad COmplex Types are.   And that the IETF does not recommend using them and thus we wont recommend your specifications.

The reality is that every SDO uses them and will continue to use them - because they solve real world problems.

Fix this document.

On 11-01-2010, at 22:50 , Alan DeKok wrote:

> Avi Lior wrote:
>> You can talk about the perils of complex types it the document that actually talks about complex types.
> 
>  Many complex types are defined in documents that are SDO and
> vendor-specific.  The IETF cannot influence those documents, other than
> by publishing an IETF BCP.
> 
>  So... we have the "guidelines" document.
> 
>  The "extended attributes" document talks about the "extended
> attributes" complex type.  SDOs and vendors will *still* create complex
> types not matching that document.  There needs to be guidelines to cover
> those situations.
> 
>  So... we have the "guidelines" document.
> 
>  Alan DeKok.

Delivery-date: Tue, 12 Jan 2010 03:50:44 +0000
Date: Tue, 12 Jan 2010 04:50:17 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> You can talk about the perils of complex types it the document that actually talks about complex types.

  Many complex types are defined in documents that are SDO and
vendor-specific.  The IETF cannot influence those documents, other than
by publishing an IETF BCP.

  So... we have the "guidelines" document.

  The "extended attributes" document talks about the "extended
attributes" complex type.  SDOs and vendors will *still* create complex
types not matching that document.  There needs to be guidelines to cover
those situations.

  So... we have the "guidelines" document.

  Alan DeKok.

Delivery-date: Tue, 12 Jan 2010 03:04:43 +0000
From: Avi Lior <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Mon, 11 Jan 2010 22:03:41 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 11-01-2010, at 15:21 , David B. Nelson wrote:

> On Jan 11, 2010, at 2:44 PM, Avi Lior wrote:
> 
>> If you want to make progress then do something about the complex  
> attributes
>> and other areas that are problematic.
> 
> That's not for me to say.  We require WG consensus to do that, and the  
> consensus we have is to defer such issues to the RADIUS Extended  
> Attributes document and leave "traditional" RADIUS pretty much alone.
I didnt mean do something as in address them.  I mean do something as in address the issues that are being raised.

> 
>> It seems from the remark you are making you a suggesting that we stop
>> complaining about these complex attributes and other things.
> 
> I *am* suggesting that you (and others) channel that energy into a  
> vehicle that currently has WG consensus to address such issues, namely  
> the RADIUS Extended Attributes document.
Well, remove the offending text in the guideline.

> 
>> People like myself are tired of bringing up issues on this document  
> over
>> and over again and have them being ignored.
> 
> I understand, but at some point you may want to consider simply  
> accepting the WG consensus on this and to find another way to address  
> your issues.  Attempting to re-open closed discussions isn't productive
I am assuming that the chair(s) put the " Last Look " for some reason.  Anyway please look back in the threads on this document and you will see sustained issues with this text.  

> 
>> I can just ignore this document at the IETF but the problem is that  
> it will
>> haunt me at the SDO level.
> 
> I'm certainly not suggesting that you (or anyone) ignore the document.
Not ignore "...but channel that energy elsewhere".  Same difference no?

>> Several people told me that no one will take this document seriously
>> and that I should let it go.
> 
> Well, those who give you that advice would appear to me to not take  
> the standard process seriously.
Good. So I am taking the process seriously and i am seriously wanting to fix these issues.

> 
>> What is the purpose of this document?
> 
> The purpose is to document the Internet community's assessment of the  
> Best Current Practice for designing RADIUS Attributes for the  
> "traditional" RADIUS protocol, as defined in RFC 2865.

So complex types are not part of that model so why are we even talking about them.
Nobody is suggesting that we add new types to the traditional model.  So please delete the text - or get it right.

You can talk about the perils of complex types it the document that actually talks about complex types.  That document can have the guidelines of when it would be appropriate to have complex type and how to achieve the use of complex types.

Delivery-date: Mon, 11 Jan 2010 21:22:33 +0000
Date: Mon, 11 Jan 2010 22:21:55 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Wojciech Dec (wdec)" <[email-masked]>,  Dave Nelson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> The problem with the document is as follows:
> 
> It talks about a RADIUS model which is not really defined anywhere.

  I could have sworn that the document tries to address that.

> As an example lets talk about new code.  Depending on your view of what RADIUS is then everytime you introduce a new attribute - not a new attribute type - but just a new attribute say foobar of type int.  Then new code is required - on both the client (NAS) and the RADIUS server.  They have to process this new attribute.

  Already refuted.  See earlier messages.

> I think as long as you use the established data types, then no new code is required by the lower layer (or the RADIUS transport layer or whatever you want to call it) and the upper layer either on the client and server are impacted.  This is the AAA model that diameter uses.

  What does that have to do with RADIUS?

> That is how RADIUS is used today by most SDOs if not all.  And since RADEXT is targeting that group we want the document to reflect that usage - or as a minimum RADEXT should define the model that this BCP applies to.  Then we can agree or disagree on attributes, complexity, security, etc....

  Already addressed.

  Alan DeKok.

Delivery-date: Mon, 11 Jan 2010 20:21:55 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Mon, 11 Jan 2010 15:21:07 -0500

On Jan 11, 2010, at 2:44 PM, Avi Lior wrote:

 > If you want to make progress then do something about the complex  
attributes
 > and other areas that are problematic.

That's not for me to say.  We require WG consensus to do that, and the  
consensus we have is to defer such issues to the RADIUS Extended  
Attributes document and leave "traditional" RADIUS pretty much alone.

 > It seems from the remark you are making you a suggesting that we stop
 > complaining about these complex attributes and other things.

I *am* suggesting that you (and others) channel that energy into a  
vehicle that currently has WG consensus to address such issues, namely  
the RADIUS Extended Attributes document.

 > People like myself are tired of bringing up issues on this document  
over
 > and over again and have them being ignored.

I understand, but at some point you may want to consider simply  
accepting the WG consensus on this and to find another way to address  
your issues.  Attempting to re-open closed discussions isn't productive

 > I can just ignore this document at the IETF but the problem is that  
it will
 > haunt me at the SDO level.

I'm certainly not suggesting that you (or anyone) ignore the document.

 > Several people told me that no one will take this document seriously
 > and that I should let it go.

Well, those who give you that advice would appear to me to not take  
the standard process seriously.

 > What is the purpose of this document?

The purpose is to document the Internet community's assessment of the  
Best Current Practice for designing RADIUS Attributes for the  
"traditional" RADIUS protocol, as defined in RFC 2865.

The purpose of the RADIUS Extended Attributes document is to address  
the shortcomings of the "traditional" RADIUS data model that we are  
all very familiar with.  Or at least to partially address those  
shortcomings.  The WG consensus on that does stop short of creating  
full feature-parity with Diameter.

Delivery-date: Mon, 11 Jan 2010 19:44:40 +0000
From: Avi Lior <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Mon, 11 Jan 2010 14:44:19 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

David,

This document and the topics around this document have been problematic from day one as you say and its not just complex attributes.
> We need to make progress on both the Guidelines BCP and the Extended
> Attributes document, and continued debate over issues such as complex
> attributes is blocking progress.  It's time to move on.  Please.

If you want to make progress then do something about the complex attributes and other areas that are problematic.  It seems from the remark you are making you a suggesting that we stop complaining about these complex attributes and other things.  This has been the style in RADEXT and I am sorry but you have objections to certain topics and treatments that are as you say "been around for as long as RADEXT has been around".  Thus RADEXT had never had a rough consensus on this document - that is why we are here again.

People like myself are tired of bringing up issues on this document over and over again and have them being ignored.

I can just ignore this document at the IETF but the problem is that it will haunt me at the SDO level.  Several people told me that no one will take this document seriously and that I should let it go.  Then if that is true the why have it in the first place.  What is the purpose of this document?

In any case:

A document that tells you not to do something and yet does not offer a reasonable alternative is problematic

A document that makes assumptions about the reader's understanding of the RADIUS model - where in fact there is more then one model. Is problematic.

A document that states that SDOs can do anything they want but on the other hand says that the specification being produced are not RECOMMENDED is problematic.

I agree that with the following:  No introduction of new types as in the base attributes that RADIUS supports at least for now.

I dont agree that using a String to codify a complex attribute introduces any security risks in the base protocol - the dictionary driven side of things - because new new code has been introduced at that layer.  At the higher layer - the security risks are no different when anything new is being introduced including the introduction of a new attribute (of an existing type) - since such introduction requires code change.

I dont agree that complex attributes as those used by embedding them in a string or in a VSA are a bad thing. They are necessary.

And by the way, usage of an integer type to codify a set of flags (a bit map) has been used over and over again - there are lots of examples in the IETF such usage etc ....  i believe if you look at your email archive you will see copious examples from RADIUS.

I can go on and on..... and I have gone on and on in the past.

Delivery-date: Mon, 11 Jan 2010 19:17:53 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Wojciech Dec (wdec)" <[email-masked]>, Dave Nelson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 11 Jan 2010 14:16:48 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

Alan,

The problem with the document is as follows:

It talks about a RADIUS model which is not really defined anywhere.  The document itself talks about impacts on RADIUS and Applications and it define neither nor does it define the interactions between the RADIUS server and the Applications.  That is a huge problem because the document makes statements and when the reader has a different model in his/her brain it creates confusion.

As an example lets talk about new code.  Depending on your view of what RADIUS is then everytime you introduce a new attribute - not a new attribute type - but just a new attribute say foobar of type int.  Then new code is required - on both the client (NAS) and the RADIUS server.  They have to process this new attribute.

The view (that i get from the document) WRT to the NAS (client) new code would be required and WRT to the server no new code would be required. This is problematic.

I think as long as you use the established data types, then no new code is required by the lower layer (or the RADIUS transport layer or whatever you want to call it) and the upper layer either on the client and server are impacted.  This is the AAA model that diameter uses.

That is how RADIUS is used today by most SDOs if not all.  And since RADEXT is targeting that group we want the document to reflect that usage - or as a minimum RADEXT should define the model that this BCP applies to.  Then we can agree or disagree on attributes, complexity, security, etc....

There are other problems as I pointed out and inconsistencies that are problematic.

On 11-01-2010, at 06:05 , Alan DeKok wrote:

> Wojciech Dec (wdec) wrote:
>> With all due respect, but  this isn't terribly helpful. Based on this
>> and previous heated threads, it's my impression that the topic of
>> complex attributes and how they're described/dealt with in the "Design
>> Guidleines" document has been and clearly continues to be a bone of
>> contention, i.e. there doesn't appear to be any long standing consensus
>> on the matter.
> 
>  The main point of discussion is whether or not RADIUS is *more* than
> what is described in the documents.  I think that everyone, (including
> me), agrees that RADIUS *can* be more.
> 
>  The point of contention is whether or not it is *required* to be more.
> 
>  The document describes a model of RADIUS which is compatible with the
> original implementation and specification.  The model is also compatible
> with 100% of the RADIUS deployments today.
> 
>  The document recommends BCPs according to that model, and does not
> forbid against any behavior that is more capable than the model suggests.
> 
>  The "heat" in the discussions comes from two topics.  One, an
> accusation that the document forbids "more" from RADIUS.  And two, a
> request that the document be changed to *require* more from RADIUS.  I
> have repeatedly offered proof that (1) is wrong, and repeatedly
> suggested that (2) is out of scope of this document.
> 
>> If we want to move on with the doc, perhaps removing the
>> whole section off to another draft would be the way to go. 
> 
>  I have previously suggested writing a new document.  Please do so.
> 
>  But removing the "basic" model description from the document would
> mean that the design guidelines would refer to a non-existent design.
> That renders the document useless for all practical purposes.
> 
>  To put it another way, *requiring* a more complex model from RADIUS
> would mean that 100's of 1000's of deployments that do AAA for 100's of
> millions of users would suddenly be defined post-facto as "not matching
> the RADIUS operational model".
> 
>  This idea is *ridiculous*.  It's gaming the standards process in order
> to bypass open competition in the market place.
> 
>  Alan DeKok.
> 
> --

Delivery-date: Mon, 11 Jan 2010 15:24:16 +0000
Date: Mon, 11 Jan 2010 07:23:26 -0800 (PST)
From: Behcet Sarikaya <[email-masked]>
Reply-To: Behcet Sarikaya <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
To: "Wojciech Dec \(wdec\)" <[email-masked]>, Dave Nelson <[email-masked]>, [email-masked]

I agree with Woj.

Regards,

Behcet

----- Original Message ----
> From: Wojciech Dec (wdec) <[email-masked]>
> To: Dave Nelson <[email-masked]>; [email-masked]
> Sent: Mon, January 11, 2010 4:02:17 AM
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Dave Nelson
> > Sent: 10 January 2010 15:37
> > To: [email-masked]
> > Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> > 
> > 
> > 
> > Hey guys, the purpose of this "Last Look" call is to review 
> > small changes proposed to fix a couple of late-discovered 
> > technical issues.� We have been through WG Last Call, IETF 
> > Last Call and IESG approval on this document.
> > 
> > We are all aware that the RADIUS data defined in RFC 2865 (and a few
> > thereafter) is limited -- some would say very limiting.� 
> > After a long, long, long time the RADEXT WG reached rough 
> > consensus that the Best Current Practice for designing 
> > "traditional" RADIUS Attributes stays within the boundaries 
> > of the original RADIUS data model, and acknowledges the value 
> > of data-dictionary driven RADIUS servers.� Any expansion of 
> > the RADIUS data model is to happen in the RADIUS Extended 
> > Attributes document (which is not making good forward 
> > progress, by the way).
> > 
> > In short, the "Last Look" is not an opportunity to upset 
> > long-standing consensus, even though there are also long 
> > standing dissenters.� Let's look for technical nits in the 
> > document and move on, please.� Thank you.
> 
> With all due respect, but� this isn't terribly helpful. Based on this
> and previous heated threads, it's my impression that the topic of
> complex attributes and how they're described/dealt with in the "Design
> Guidleines" document has been and clearly continues to be a bone of
> contention, i.e. there doesn't appear to be any long standing consensus
> on the matter. If we want to move on with the doc, perhaps removing the
> whole section off to another draft would be the way to go. 
> 
> -Woj.
> 
> > 
> > 
> > 
> > 
> > 
> > --
> > to unsubscribe send a message to 
> > [email-masked] with the word 'unsubscribe' in 
> > a single line as the message text body.
> > archive: 
> > 
> 
> --
> archive: 

Delivery-date: Mon, 11 Jan 2010 12:33:03 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Mon, 11 Jan 2010 07:32:32 -0500

Wojciech Dec writes...

> Based on this and previous heated threads, it's my impression
> that the topic of complex attributes and how they're described
> / dealt with in the "Design Guidelines" document has been and
> clearly continues to be a bone of contention...

The heated debate over complex attributes is as old as the WG itself.  I
fully realize that there are a few WG members who are still unhappy with the
rough consensus that was formed on this issue.

> ... i.e. there doesn't appear to be any long standing consensus
> on the matter. 

Consensus does not mean unanimity.  We can have rough consensus in the face
of a small number of dissenters.  When rough consensus exists, sometimes you
just have to move on.

> If we want to move on with the doc, perhaps removing the
> whole section off to another draft would be the way to go.

The consensus of the WG is that formal description of complex attributes
should occur within the scope of the RADIUS Extended Attributes document,
and that "traditional" RADIUS, as defined in RFC 2865 and the Guidelines BCP
should not be formally extended to embrace that concept.

We need to make progress on both the Guidelines BCP and the Extended
Attributes document, and continued debate over issues such as complex
attributes is blocking progress.  It's time to move on.  Please.

Delivery-date: Mon, 11 Jan 2010 11:05:47 +0000
Date: Mon, 11 Jan 2010 12:05:06 +0100
From: Alan DeKok <[email-masked]>
To: "Wojciech Dec (wdec)" <[email-masked]>
CC: Dave Nelson <[email-masked]>, [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Wojciech Dec (wdec) wrote:
> With all due respect, but  this isn't terribly helpful. Based on this
> and previous heated threads, it's my impression that the topic of
> complex attributes and how they're described/dealt with in the "Design
> Guidleines" document has been and clearly continues to be a bone of
> contention, i.e. there doesn't appear to be any long standing consensus
> on the matter.

  The main point of discussion is whether or not RADIUS is *more* than
what is described in the documents.  I think that everyone, (including
me), agrees that RADIUS *can* be more.

  The point of contention is whether or not it is *required* to be more.

  The document describes a model of RADIUS which is compatible with the
original implementation and specification.  The model is also compatible
with 100% of the RADIUS deployments today.

  The document recommends BCPs according to that model, and does not
forbid against any behavior that is more capable than the model suggests.

  The "heat" in the discussions comes from two topics.  One, an
accusation that the document forbids "more" from RADIUS.  And two, a
request that the document be changed to *require* more from RADIUS.  I
have repeatedly offered proof that (1) is wrong, and repeatedly
suggested that (2) is out of scope of this document.

> If we want to move on with the doc, perhaps removing the
> whole section off to another draft would be the way to go. 

  I have previously suggested writing a new document.  Please do so.

  But removing the "basic" model description from the document would
mean that the design guidelines would refer to a non-existent design.
That renders the document useless for all practical purposes.

  To put it another way, *requiring* a more complex model from RADIUS
would mean that 100's of 1000's of deployments that do AAA for 100's of
millions of users would suddenly be defined post-facto as "not matching
the RADIUS operational model".

  This idea is *ridiculous*.  It's gaming the standards process in order
to bypass open competition in the market place.

  Alan DeKok.

Delivery-date: Mon, 11 Jan 2010 10:03:33 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Mon, 11 Jan 2010 11:02:17 +0100
To: "Dave Nelson" <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Nelson
> Sent: 10 January 2010 15:37
> To: [email-masked]
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> <chair-hat>
> 
> Hey guys, the purpose of this "Last Look" call is to review 
> small changes proposed to fix a couple of late-discovered 
> technical issues.  We have been through WG Last Call, IETF 
> Last Call and IESG approval on this document.
> 
> We are all aware that the RADIUS data defined in RFC 2865 (and a few
> thereafter) is limited -- some would say very limiting.  
> After a long, long, long time the RADEXT WG reached rough 
> consensus that the Best Current Practice for designing 
> "traditional" RADIUS Attributes stays within the boundaries 
> of the original RADIUS data model, and acknowledges the value 
> of data-dictionary driven RADIUS servers.  Any expansion of 
> the RADIUS data model is to happen in the RADIUS Extended 
> Attributes document (which is not making good forward 
> progress, by the way).
> 
> In short, the "Last Look" is not an opportunity to upset 
> long-standing consensus, even though there are also long 
> standing dissenters.  Let's look for technical nits in the 
> document and move on, please.  Thank you.

With all due respect, but  this isn't terribly helpful. Based on this
and previous heated threads, it's my impression that the topic of
complex attributes and how they're described/dealt with in the "Design
Guidleines" document has been and clearly continues to be a bone of
contention, i.e. there doesn't appear to be any long standing consensus
on the matter. If we want to move on with the doc, perhaps removing the
whole section off to another draft would be the way to go. 

-Woj.

> 
> </chair-hat>
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Sun, 10 Jan 2010 17:39:56 +0000
Date: Sun, 10 Jan 2010 18:39:01 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> On 06-01-2010, at 15:54 , Alan DeKok wrote:
>>  If this isn't clear, we can put it in 50pt blinking neon text.
>
> Not only it is not clear but also not true and I want it to be true ...  In section 3.1.1  there is text that contradicts what you say.  Here it is:
> 
> "
> The design and specification of VSAs for multi-vendor usage SHOULD be

  SHOULD != MUST

  This is a BCP document.  If SDOs choose to ignore the SHOULDs, they
will not be following BCP.  But there is *nothing* in the document that
prevents them from ignoring the BCP recommendations.

> So reading the document with respect to SDOs....
> 
> In section 3.1.1 please remove the "stuff" related to SDO Specific Attribute (SSA).
> This is only going to create confusion.

  How?

>  Either RADEXT formally adopts this usage or not.  I would argue that it is too late.

  There appeared to be consensus that this usage was OK for the BCP.
The document has passed a number of last calls && IESG reviews.

> By specification i assume that you mean SDO specifications.  Right?  well you should state that.

  Vendor or SDO specifications.  That should be clear from the context.

> Assuming that is correct then i have a problem with the text...
> 
> I dont think that the IETF has a say on whether they can prohibit or "not recommend" or even recommend an SDO specification. 

  You're right.  The IETF has no control over any IETF protocol, and
should give up now.   It's *crazy* talk for the IETF to suggest how the
IETF protocols should be used.  I mean, who's kidding, who?  An IETF BCP
should apply only to the IETF, and SDOs should pay *zero* attention to it.

> I think you have captured what needs to be captured in the previous part and also in the following paragraph.
> 
> And also what does it mean that all the attributes are VSA....  you mean i cant reuse an attribute such as User-Name as defined by 2865 in my SDO specification.  I don't agree with that.

  You can't re-define it.

  Alan DeKok.

Delivery-date: Sun, 10 Jan 2010 15:54:26 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 10 Jan 2010 10:53:31 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 06-01-2010, at 15:54 , Alan DeKok wrote:

> Avi Lior wrote:
>> Great!!!! But this also creates confusion.  Because what is RADIUS.....
>> 
>> IETF publishes a document that says its BAD to do something if it is RADIUS and not bad if it is not RADIUS --- then it better define what is meant by RADIUS.  Otherwise I have to live with the debate for the rest of my SDO life.
> 
>  The guidelines document says "SDOs do whatever the heck they want".
> 
>  If this isn't clear, we can put it in 50pt blinking neon text.
> 

Not only it is not clear but also not true and I want it to be true ...  In section 3.1.1  there is text that contradicts what you say.  Here it is:

"
The design and specification of VSAs for multi-vendor usage SHOULD be
   undertaken with the same level of care as standard RADIUS attributes.
   Specifically, the provisions of this document that apply to standard
   RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage."

Please get rid of that text!

Also in 3.1.3 ....

It is RECOMMENDED that SDOs follow the guidelines
   outlined here, which are intended to enable maximum interoperability
   with minimal changes to existing systems.

Also since you already have an applicability section and you already make the recommendations that SDOs and vendors follow this document -- you dont need to repeat yourself over and over again.  So please get rid of the repeated text.

So reading the document with respect to SDOs....

In section 3.1.1 please remove the "stuff" related to SDO Specific Attribute (SSA).
This is only going to create confusion.  Either RADEXT formally adopts this usage or not.  I would argue that it is too late.

  As a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific
   Attribute" to refer to an encoding format which can be used by
   individual vendors to define attributes not suitable for general
   usage.  However, since then VSAs have also become widely used by SDOs
   defining attributes intended for multi-vendor interoperability. As
   such, these attributes are not specific to any single vendor, and the
   term "Vendor-Specific" may be misleading.  An alternate term which
   better describes this use case is SDO-Specific Attribute (SSA).

Thus in section 3.1.1 the last two paragraphs should go.

Back to applicablity section 1.3

"It is RECOMMENDED that SDOs follow the guidelines articulated in this
   document.  Doing so will ensure the widest possible applicability and
   interoperability of the specifications, while requiring minimal
   changes to existing systems. ....
This is fine but the rest is problematic...
"
 Specifications that do not follow the
   guidelines articulated herein are NOT RECOMMENDED.  However, we
   recognize that there are some situations where SDOs or vendors
   require the creation of specifications not following these
   guidelines.  We do not forbid these specifications, but it is
   RECOMMENDED that they are created only if they have a limited scope
   of applicability, and all attributes defined in those specifications
   are VSAs, as discussed Appendix A.5, below."

By specification i assume that you mean SDO specifications.  Right?  well you should state that.

Assuming that is correct then i have a problem with the text...

I dont think that the IETF has a say on whether they can prohibit or "not recommend" or even recommend an SDO specification.  I think you have captured what needs to be captured in the previous part and also in the following paragraph.

And also what does it mean that all the attributes are VSA....  you mean i cant reuse an attribute such as User-Name as defined by 2865 in my SDO specification.  I don't agree with that.

Delivery-date: Sun, 10 Jan 2010 15:00:31 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 10 Jan 2010 10:00:08 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

See inline
On 10-01-2010, at 05:41 , Alan DeKok wrote:

> Avi Lior wrote:
>> I still think it is silly  -  it is saying that a new things are buggy and potentially have security issues.
>> 
>> But so is the use of a new attribute using an existing data type.
> 
>  Again, the logical fallacy of "change is change, so all change has the
> same risk".
sure ... some change has more risk then other changes....but it is obvious no?  Why talk about it...but if you must then go ahead...

> 
>> But anyway if you insist on having some text about new data types then look at my changes.
> ...
>> New text..... AND MOVE THIS TO THE SECURITY SECTION....
>> 
>> 2.1.4.  New Data types and Security
>> 
>>   The introduction of NEW data types brings the potential for the
>>   introduction of new security vulnerabilities.
> 
>  That's true, though it encourages view that simple changes have the
> same risk as complex ones.  This isn't true, and the existing text does
> not have that problem.
So make up your mind! first you tell me this is not about complex attributes and now you tell me it is!  

"Emphasis on "new", not "complex"." is what you wrote in the previous email.  So make it so.  Please use my corrected text.

> 
>> """ TAKE THE FOLLOWING TWO PARAGRAPHS OUT SINCE YOU ARE TALKING ABOUT RADIUS IN THIS DOCUMENT. """
> 
>  Those paragraphs talk about BCP for RADIUS.  (The word RADIUS appears
> 4 times in the two paragraphs).  If they ignored RADIUS, and only
> discussed application-layer issues, I could see your point.
Just because you use the word RADIUS one hundred times in said paragraphs does not make the paragraphs about RADIUS.  There paragraphs speak about an "applications" 

"The threat merely moves from the RADIUS server to the
  application that consumes that opaque data."
The subject is the Application not RADIUS....did i miss something here?

"Applications consuming opaque data that
  reside on the RADIUS server SHOULD be properly isolated from the
  RADIUS server,..." 
The subject is the application right?  did I miss something.

So out of the 4 RADIUS instances 3 of them were about the Application

The fourth one:

"The threat is particularly severe when the opaque data originates
  from the user, and is not validated by the NAS.  In those cases, the
  RADIUS server is potentially exposed to attack by malware residing on
  an unauthenticated host."

Is probably about the Application since it is not validated by the NAS.  The other point about this particular text and the section is at one hand you are talking about new data types and the risks of them.  And intermixed with that you talk about opaque data.  Opaque data does not require new code in the RADIUS server.  It requires no code in the RADIUS server.  This is another reason why the paragraphs dont make sense so get rid of them.

So again since you insist this is document is about RADIUS and not applications.  And you dont want to define applications.  Then dont talk about applications.  Just remove these paragraphs!

You asked for text -- I gave you text.  You haven't convinced me that my text is invalid.  So what seems to be the problem?

> 
>  But the text could arguably appear in the security section of the
> document.  There's no compelling reason to keep it in the main body of
> the document.

Great.
>  Alan DeKok.

Delivery-date: Sun, 10 Jan 2010 14:37:46 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Sun, 10 Jan 2010 09:36:40 -0500

<chair-hat>

Hey guys, the purpose of this "Last Look" call is to review small changes
proposed to fix a couple of late-discovered technical issues.  We have been
through WG Last Call, IETF Last Call and IESG approval on this document.

We are all aware that the RADIUS data defined in RFC 2865 (and a few
thereafter) is limited -- some would say very limiting.  After a long, long,
long time the RADEXT WG reached rough consensus that the Best Current
Practice for designing "traditional" RADIUS Attributes stays within the
boundaries of the original RADIUS data model, and acknowledges the value of
data-dictionary driven RADIUS servers.  Any expansion of the RADIUS data
model is to happen in the RADIUS Extended Attributes document (which is not
making good forward progress, by the way).

In short, the "Last Look" is not an opportunity to upset long-standing
consensus, even though there are also long standing dissenters.  Let's look
for technical nits in the document and move on, please.  Thank you.

</chair-hat>

Delivery-date: Sun, 10 Jan 2010 10:42:24 +0000
Date: Sun, 10 Jan 2010 11:41:39 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> I still think it is silly  -  it is saying that a new things are buggy and potentially have security issues.
> 
> But so is the use of a new attribute using an existing data type.

  Again, the logical fallacy of "change is change, so all change has the
same risk".

>  But anyway if you insist on having some text about new data types then look at my changes.
...
> New text..... AND MOVE THIS TO THE SECURITY SECTION....
> 
> 2.1.4.  New Data types and Security
> 
>    The introduction of NEW data types brings the potential for the
>    introduction of new security vulnerabilities.

  That's true, though it encourages view that simple changes have the
same risk as complex ones.  This isn't true, and the existing text does
not have that problem.

> """ TAKE THE FOLLOWING TWO PARAGRAPHS OUT SINCE YOU ARE TALKING ABOUT RADIUS IN THIS DOCUMENT. """

  Those paragraphs talk about BCP for RADIUS.  (The word RADIUS appears
4 times in the two paragraphs).  If they ignored RADIUS, and only
discussed application-layer issues, I could see your point.

  But the text could arguably appear in the security section of the
document.  There's no compelling reason to keep it in the main body of
the document.

  Alan DeKok.

Delivery-date: Sun, 10 Jan 2010 05:03:10 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 10 Jan 2010 00:01:52 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 09-01-2010, at 07:47 , Alan DeKok wrote:

> Avi Lior wrote:
>> Sorry i have more to say......
>> 
>> Section 2.1.4 makes the following assertion. Exchanging information as a complex type has potential for introducing more security vulnerabilities.
> 
>  It doesn't say that.
> 
>  It says:
> 
>   ... New data types require
>   new code, which may introduce new bugs, and therefore new attack
>   vectors.
> 
>  Emphasis on "new", not "complex".

Execuse me !!!!  The whole section is titled   Complex Attributes and Security ( I have pasted the text for  you at the bottom. )

And also this sentence:  "An extreme outcome of a vulnerability due to a new,
   complex type "   --- again what is this section about??????

But to align it with what you think it is about I have suggested new text.

I still think it is silly  -  it is saying that a new things are buggy and potentially have security issues.

But so is the use of a new attribute using an existing data type.  But anyway if you insist on having some text about new data types then look at my changes.

Original text....

2.1.4.  Complex Attributes and Security

   The introduction of complex data types brings the potential for the
   introduction of new security vulnerabilities.  Experience shows that
   the common data types have few security vulnerabilities, or else that
   all known issues have been found and fixed.  New data types require
   new code, which may introduce new bugs, and therefore new attack
   vectors.

   RADIUS servers are highly valued targets, as they control network
   access and interact with databases that store usernames and
   passwords.  An extreme outcome of a vulnerability due to a new,
   complex type would be that an attacker is capable of taking complete
   control over the RADIUS server.

   The use of attributes representing opaque data does not reduce this
   threat.  The threat merely moves from the RADIUS server to the
   application that consumes that opaque data.

   The threat is particularly severe when the opaque data originates
   from the user, and is not validated by the NAS.  In those cases, the
   RADIUS server is potentially exposed to attack by malware residing on
   an unauthenticated host.  Applications consuming opaque data that
   reside on the RADIUS server SHOULD be properly isolated from the
   RADIUS server, and SHOULD run with minimal privileges.  Any potential
   vulnerabilities in that application will then have minimal impact on
   the security of the system as a whole.

New text..... AND MOVE THIS TO THE SECURITY SECTION....

2.1.4.  New Data types and Security

   The introduction of NEW data types brings the potential for the
   introduction of new security vulnerabilities.  Experience shows that
   the existing data types have few security vulnerabilities, or else that
   all known issues have been found and fixed.  New data types require
   new code, which may introduce new bugs, and therefore new attack
   vectors.

   RADIUS servers are highly valued targets, as they control network
   access and interact with databases that store usernames and
   passwords.  An extreme outcome of a vulnerability due to a new attribute type would be that an attacker is capable of taking complete
   control over the RADIUS server.

""" TAKE THE FOLLOWING TWO PARAGRAPHS OUT SINCE YOU ARE TALKING ABOUT RADIUS IN THIS DOCUMENT. """

   The use of attributes representing opaque data does not reduce this
   threat.  The threat merely moves from the RADIUS server to the
   application that consumes that opaque data.

   The threat is particularly severe when the opaque data originates
   from the user, and is not validated by the NAS.  In those cases, the
   RADIUS server is potentially exposed to attack by malware residing on
   an unauthenticated host.  Applications consuming opaque data that
   reside on the RADIUS server SHOULD be properly isolated from the
   RADIUS server, and SHOULD run with minimal privileges.  Any potential
   vulnerabilities in that application will then have minimal impact on
   the security of the system as a whole.

Delivery-date: Sat, 09 Jan 2010 12:48:38 +0000
Date: Sat, 09 Jan 2010 13:47:39 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> Sorry i have more to say......
> 
> Section 2.1.4 makes the following assertion. Exchanging information as a complex type has potential for introducing more security vulnerabilities.

  It doesn't say that.

  It says:

   ... New data types require
   new code, which may introduce new bugs, and therefore new attack
   vectors.

  Emphasis on "new", not "complex".

> What?
> 
> You mean if i have to send the following information element a b c to the client or the server; if i send them concatenated in one attribute as say a String foobar containing a+b+c or that will pose more of a security risk the sending them as three separate attributes.
> 
> Help me understand this.....

  I think this message is the third or fourth re-iteration of the topic.
  From now on, I will simply ignore nonsensical claims about the document.

> I think it would be worth while to define the RADIUS model first.  Not the old RADIUS model but rather the one that we are all living with today.  That model is not really different then Diameter.
> 
> Where:
> 
> we have an Application layer and a Base layer.
> 
> Then define the roles of each.

  Suggest some text.

  Or... perhaps we shouldn't re-visit the design of RADIUS.  We've
already gone through one set of revisions where the guidelines document
was attacked because of inconsistencies in the original RFCs.

  The guidelines document is *not* attempting to re-define RADIUS.
Creating a spurious dependency on re-defining RADIUS is a blatant
attempt to shut down the document for more years of revision.

  For a more detailed explanation, see my earlier message:

http://ops.ietf.org/lists/radiusext/2009/msg00612.html

> Where is parsing done and what type of parsing is done.
> Which layer is responsible for security and to what extent.  It seems that security is the responsibility for both layers but not to the same extent.
> 
> The role of the dictionary...
> 
> The document intermixes these topics ....  and I am telling you this will create confusion
> 
> 
> I want a more formal definition.

  Write one.

  In another document.

> BTW on that note....in section 1.1 You define RADIUS proxy but the term is never used anywhere!!!! I find that hard to believe - cause I am sure we would have to say something about Proxies.  

  I'll delete the definition.

  Or, you can suggest some "guidelines" text for RADIUS proxies.

> I think if we did talk about RADIUS as an APplication layer and transport layer etc then we would have to say something about Proxies.

  Seeing as you have no suggestions about what to say, I think the
document is adequate as is.

  Alan DeKok.

Delivery-date: Thu, 07 Jan 2010 22:19:45 +0000
From: "David B. Nelson" <[email-masked]>
To: [email-masked]
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Date: Thu, 7 Jan 2010 17:19:12 -0500

On Jan 7, 2010, at 4:54 PM, Joseph Salowey (jsalowey) wrote:

> [Joe] Regardless of whether it changes the basic processing model of
> RADIUS or not, the processing of "string" attribtues has the same
> security implications of complex attributes.

That presumes that "string" attributes should be processed.  If the  
the only operations performed on strings are to compare them for match  
with other strings, they're not much risk.  It's when you assume that  
strings are more than simply names in some namespace that you can get  
into trouble.

Delivery-date: Thu, 07 Jan 2010 21:55:39 +0000
Content-class: urn:content-classes:message
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Thu, 7 Jan 2010 13:54:42 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Monday, December 21, 2009 12:19 AM
> To: Bernard Aboba
> Cc: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> Bernard Aboba wrote:
> > It also occurs to me that some of the same security risks could be 
> > present in simple attributes.  For example, even though a "string"
> > attribute might be widely implemented, if an attribute 
> incorporates a 
> > new concatenation mechanism,
> 
>   Then it involves changes to the basic operating model of 
> RADIUS, where attributes are independent.  This requires code 
> changes, and all that implies.
> 
[Joe] Regardless of whether it changes the basic processing model of
RADIUS or not, the processing of "string" attribtues has the same
security implications of complex attributes.  

>   Alan DeKok.

Delivery-date: Wed, 06 Jan 2010 22:25:53 +0000
Date: Wed, 6 Jan 2010 14:24:55 -0800 (PST)
From: Behcet Sarikaya <[email-masked]>
Reply-To: Behcet Sarikaya <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
To: Alan DeKok <[email-masked]>
Cc: "[email-masked]\"" <[email-masked]>

Hi Alan,

----- Original Message ----
> From: Alan DeKok <[email-masked]>
> To: Avi Lior <[email-masked]>
> Cc: Joseph Salowey (jsalowey) <[email-masked]>; Bernard Aboba <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wed, January 6, 2010 2:54:24 PM
> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
> 
> Avi Lior wrote:
> > Great!!!! But this also creates confusion.� Because what is RADIUS.....
> > 
> > IETF publishes a document that says its BAD to do something if it is RADIUS 
> and not bad if it is not RADIUS --- then it better define what is meant by 
> RADIUS.� Otherwise I have to live with the debate for the rest of my SDO life.
> 
> � The guidelines document says "SDOs do whatever the heck they want".
> 
> � If this isn't clear, we can put it in 50pt blinking neon text.

With this, I think that Radext is going to become the WG (possibly the only one) that does not care about SDOs.

Regards,

Behcet

Delivery-date: Wed, 06 Jan 2010 20:55:01 +0000
Date: Wed, 06 Jan 2010 21:54:24 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> Great!!!! But this also creates confusion.  Because what is RADIUS.....
> 
> IETF publishes a document that says its BAD to do something if it is RADIUS and not bad if it is not RADIUS --- then it better define what is meant by RADIUS.  Otherwise I have to live with the debate for the rest of my SDO life.

  The guidelines document says "SDOs do whatever the heck they want".

  If this isn't clear, we can put it in 50pt blinking neon text.

> Issue 1: we are missing some text in the last paragraph of section 2.0  RADIUS Data Model
> 
> "The similarity between
>    attribute formats has enabled implementations to leverage common
>    parsing functionality, although in some cases the attributes in the"

  Hmm... I'll check the revision control to see what happened to that.

> Issue 2:
> 
> 2.1.2  Tagging
> 
> " For these reasons, the tagging scheme described in RFC 2868 is NOT
>    RECOMMENDED for use as a generic grouping mechanism."
> 
> Great and I agree!!!  So what is recommended??? Solve the problem.

  I'll run away from *that* discussion.  The document is "guidelines",
not "redesigning RADIUS".  Some later document will recommend a better
solution.

> Complex Attribute Usage is one way to solve this problem...We should state that.

  That recommendation was in the document, and was removed after RADEXT
discussions.  It can't really be added back.

> Issue 2.1.3
> 
> The entire language of this section is about AAA application layer vs parsing by AAA transport layer.
> 
> User data entry is application layer
> Additional error checking is application layer
> Simplifies implementation is by appliation layer
> 
> " One of the fundamental goals of the RADIUS protocol design was to
>    allow RADIUS servers to be configured to support new attributes
>    without requiring server code changes."
> 
> So how do i add a QoS attributes to RADIUS without  code changes?

  I dunno.  The document doesn't add new attributes.  It suggests how to
get the most out of the existing RADIUS functionality.

> we need to think about how we use RADIUS today vs what we did in the past.  This is after all a Best Current Practice document, right?

 It's a BCP, not a "this is what we SHOULD have done".

> If i am sending 6 QoS profiles over RADIUS with each QoS profile consisting of several attributes then i need grouping of some sorts to group the classifer with the relevant qos attributes.

  Great!  Write an IETF draft, or an SDO specification.  Either way, the
guidelines document isn't affected.

> IPFilterRule is a complex type....
> 
> The message you are sending in section 2.1.3 makes no sense.
> 
> So  after reading the document - I still have a problem with 2.1.3
> 
> 
> Next ....
> 
> "On the RADIUS client, code changes are typically required in order to
>    implement a new attribute.  The RADIUS client typically has to
>    compose the attribute dynamically when sending.  When receiving, a
>    RADIUS client needs to be able to parse the attribute and carry out
>    the requested service.  As a result, a detailed understanding of the
>    new attribute is required on clients, and data dictionaries are less
>    useful on clients than on servers."
> 
> The par. above make no sense.  It is equally true for the server to have to parse attributes in an access-request to carryout its authentication and more so its authorization.  In the old days i would agree with you but now????? No way.

  Hmm... it might not be perfect, but it does make some kind of sense.
I welcome suggestions for replacement text.

> Same is true for the next paragraph.....
> 
> This section simply refuses to recognize what is really going on in RADIUS land.
> 
> 
> "Given these limitations, the introduction of complex attributes can
>    require code changes on the RADIUS server which would be unnecessary
>    if basic data types had been used instead.  "
> 
> Nonsense.  So having a NAS sending its capabiities to the RADIUS server as a set of standard attributes will not require code changes?  The RADIUS server will happily understand them and be able to take the correct action(s) ????
>
> So while I almost believe you when I read your assertion in the email...when I read the text all goes out the window.
> 
> We better define what you mean by RADIUS.....  Because section 2.1.3 is all about Application Layer stuff.

  Please suggest better text.  The existing text has been word-smithed
nearly to death.  I would like to see someone else suggest new text, so
I don't get blamed for issues with the document.

> I agree with this --- But the problem is that we don't know what is RADIUS.  So lets get that defined first.

  Suggest some text.

  Alan DeKok.

Delivery-date: Wed, 06 Jan 2010 19:29:28 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 6 Jan 2010 14:28:51 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

Sorry i have more to say......

Section 2.1.4 makes the following assertion. Exchanging information as a complex type has potential for introducing more security vulnerabilities.

What?

You mean if i have to send the following information element a b c to the client or the server; if i send them concatenated in one attribute as say a String foobar containing a+b+c or that will pose more of a security risk the sending them as three separate attributes.

Help me understand this.....

=====

I think it would be worth while to define the RADIUS model first.  Not the old RADIUS model but rather the one that we are all living with today.  That model is not really different then Diameter.

Where:

we have an Application layer and a Base layer.

Then define the roles of each.

Where is parsing done and what type of parsing is done.
Which layer is responsible for security and to what extent.  It seems that security is the responsibility for both layers but not to the same extent.

The role of the dictionary...

The document intermixes these topics ....  and I am telling you this will create confusion

I want a more formal definition.

BTW on that note....in section 1.1 You define RADIUS proxy but the term is never used anywhere!!!! I find that hard to believe - cause I am sure we would have to say something about Proxies.  

I think if we did talk about RADIUS as an APplication layer and transport layer etc then we would have to say something about Proxies.

Delivery-date: Wed, 06 Jan 2010 19:07:01 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 6 Jan 2010 14:05:47 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

On 06-01-2010, at 09:57 , Alan DeKok wrote:

> Avi Lior wrote:
>> I dont agree with that.  You should not make a judgement call about my application layer.  A complex attribute embedded in a VSA or a String does not make RADIUS layer complex!!!
> 
>  The document states *clearly* that transporting complex attributes is
> fine, so long as it is opaque to RADIUS.
Great!!!! But this also creates confusion.  Because what is RADIUS.....

IETF publishes a document that says its BAD to do something if it is RADIUS and not bad if it is not RADIUS --- then it better define what is meant by RADIUS.  Otherwise I have to live with the debate for the rest of my SDO life.

> 
>  If the attributes are *not* opaque to RADIUS, then all of my previous
> comments about complexity apply.
> 
>> You are asserting that grouping of attributes together adds complexity and I am saying that that is not neccessarily true.
> 
>  I'm pretty sure I never said that.
well... complex types is grouping of attributes and by that nexus I am pretty sure you are saying that.

> 
>> I think you should let the Designer of the "Application" decide - or do a better job talking about design practices of the Application layer.  I rather we keep silence about practices at the application layer.
> 
>  The document *explicitly* states that transport of opaque data (i.e.
> application data) is permitted.
> 
>  I am already doing what you request.  Please read the document.

So I am again....

Issue 1: we are missing some text in the last paragraph of section 2.0  RADIUS Data Model

"The similarity between
   attribute formats has enabled implementations to leverage common
   parsing functionality, although in some cases the attributes in the"

Issue 2:

2.1.2  Tagging

" For these reasons, the tagging scheme described in RFC 2868 is NOT
   RECOMMENDED for use as a generic grouping mechanism."

Great and I agree!!!  So what is recommended??? Solve the problem.

Complex Attribute Usage is one way to solve this problem...We should state that.

Issue 2.1.3

The entire language of this section is about AAA application layer vs parsing by AAA transport layer.

User data entry is application layer
Additional error checking is application layer
Simplifies implementation is by appliation layer

" One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes."

So how do i add a QoS attributes to RADIUS without  code changes?

we need to think about how we use RADIUS today vs what we did in the past.  This is after all a Best Current Practice document, right?

If i am sending 6 QoS profiles over RADIUS with each QoS profile consisting of several attributes then i need grouping of some sorts to group the classifer with the relevant qos attributes.

IPFilterRule is a complex type....

The message you are sending in section 2.1.3 makes no sense.

So  after reading the document - I still have a problem with 2.1.3

Next ....

"On the RADIUS client, code changes are typically required in order to
   implement a new attribute.  The RADIUS client typically has to
   compose the attribute dynamically when sending.  When receiving, a
   RADIUS client needs to be able to parse the attribute and carry out
   the requested service.  As a result, a detailed understanding of the
   new attribute is required on clients, and data dictionaries are less
   useful on clients than on servers."

The par. above make no sense.  It is equally true for the server to have to parse attributes in an access-request to carryout its authentication and more so its authorization.  In the old days i would agree with you but now????? No way.

Same is true for the next paragraph.....

This section simply refuses to recognize what is really going on in RADIUS land.

"Given these limitations, the introduction of complex attributes can
   require code changes on the RADIUS server which would be unnecessary
   if basic data types had been used instead.  "

Nonsense.  So having a NAS sending its capabiities to the RADIUS server as a set of standard attributes will not require code changes?  The RADIUS server will happily understand them and be able to take the correct action(s) ????

So while I almost believe you when I read your assertion in the email...when I read the text all goes out the window.

We better define what you mean by RADIUS.....  Because section 2.1.3 is all about Application Layer stuff.

> 
>> I think the push back is based on the fact that we are disagreeing on the application.  If we rely on the RADIUS layer to parse the attributes then yes it is complex.  But this is not about the RADIUS layer.  And the use of these grouped AVPs is actually reduces complexity.
> 
>  The document and this list is about RADIUS.  I have no comments on
> non-RADIUS application data.  It now seems that your comments are not
> about RADIUS, and therefore are either already addressed in the
> document, or are irrelevant to RADIUS.
> 
>  i.e. If this isn't about RADIUS, then the discussion can stop now.
> 
I agree with this --- But the problem is that we don't know what is RADIUS.  So lets get that defined first.

Then we can take all non-RADIUS text out of the document.

>  Alan DeKok.

Delivery-date: Wed, 06 Jan 2010 14:58:25 +0000
Date: Wed, 06 Jan 2010 15:57:45 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> I dont agree with that.  You should not make a judgement call about my application layer.  A complex attribute embedded in a VSA or a String does not make RADIUS layer complex!!!

  The document states *clearly* that transporting complex attributes is
fine, so long as it is opaque to RADIUS.

  If the attributes are *not* opaque to RADIUS, then all of my previous
comments about complexity apply.

> You are asserting that grouping of attributes together adds complexity and I am saying that that is not neccessarily true.

  I'm pretty sure I never said that.

> I think you should let the Designer of the "Application" decide - or do a better job talking about design practices of the Application layer.  I rather we keep silence about practices at the application layer.

  The document *explicitly* states that transport of opaque data (i.e.
application data) is permitted.

  I am already doing what you request.  Please read the document.

> I think the push back is based on the fact that we are disagreeing on the application.  If we rely on the RADIUS layer to parse the attributes then yes it is complex.  But this is not about the RADIUS layer.  And the use of these grouped AVPs is actually reduces complexity.

  The document and this list is about RADIUS.  I have no comments on
non-RADIUS application data.  It now seems that your comments are not
about RADIUS, and therefore are either already addressed in the
document, or are irrelevant to RADIUS.

  i.e. If this isn't about RADIUS, then the discussion can stop now.

  Alan DeKok.

Delivery-date: Wed, 06 Jan 2010 14:28:50 +0000
From: Avi Lior <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 6 Jan 2010 09:27:41 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

I want to start with this point first...

>> 
>> I dont understand ( i never understood) what is the objection around this!!!!
> 
>  The objection I have to your arguments is that they argue against a
> position that is not reflected in the document.  They impose a false
> dichotomy by treating all code changes identically.
> 
>  The document says this:  Simplicity is preferred to complexity.
> Complexity is acceptable in some circumstances.  Complex changes have
> higher risk than simple changes.

I dont agree with that.  You should not make a judgement call about my application layer.  A complex attribute embedded in a VSA or a String does not make RADIUS layer complex!!!

You are asserting that grouping of attributes together adds complexity and I am saying that that is not neccessarily true.

I think you should let the Designer of the "Application" decide - or do a better job talking about design practices of the Application layer.  I rather we keep silence about practices at the application layer.

Grouping of attributes does not introduce complexity but rather reduces it!!!

> 
> 
>  There has been *major* opposition to these statements.  The push seems
> to be that we should have no preference between complexity and
> simplicity, because all code changes are equal, and complex systems are
> no different than simple ones.

I think the push back is based on the fact that we are disagreeing on the application.  If we rely on the RADIUS layer to parse the attributes then yes it is complex.  But this is not about the RADIUS layer.  And the use of these grouped AVPs is actually reduces complexity.

> 
>  50 years of computer science practice shows this argument to be false.
Great point:  50 years of computer science brought us from flat attributes to grouped attributes to objects etc...So what is your point?

> 
>  If you have found a way to make complex changes no more expensive or
> risky than simple changes, you have discovered practices that will
> revolutionize computer science, and will make you personally wealthy.

As the saying goes, from you lips to God's ears!!!!

But i dont think that what we are talking about is so revolutionary.  So I cant take credit for that.  In fact,  it seems that only in RADEXT this is an issue...

Then for other reaction See inline...

On 06-01-2010, at 03:38 , Alan DeKok wrote:

> Avi Lior wrote:
>> When one receives a string that one has to parse then it requires code change - or specific code to parse the string.
> 
>  Code changes are not all the same.
I dont even know how to respond to that.
> 
>> A complex attribute is no different then a string.
> 
>  What ever happened to "KISS"?
What makes you think that a C-Struct is not KISS?
What makes you think that a Group AVP in Diameter is not KISS?

I would argue that it is KISS to group attributes that function together in a single attribute as compared with coming up with concepts like "tags" to try to achieve the same result!!!

I really really dont understand why you would think that a "COMPLEX" attribute does not follow the KISS doctrine.

> 
>> In fact code change is required anytime one has to process any attribute beyond simply transporting the message to the next hop.  Whether  it is at the client, the proxy or the server.
> 
> In fact, bits are exchanged when a client talks to a server, and all
> bits are equal.  So DNS packets (composed of bits) are interchangeable
> with RADIUS packets (composed of bits).
> 
>  Hmm... there's a logical fallacy in that argument...
Correct at the IP layer say.  The payload is simply passed along without the entities doing the transport having to care about what is in the payload.

Similarly, AAA entities that dont need to know what is in the string can pass the string along without carrying what is in it.  But eventually somebody will care about what is inside that string and that entity would have specific code to deal with processing the string.

So is the same if we use a RADIUS attribute of type int.  Entities in the AAA chain can pass it along without understanding the meaning of the AVP and only those parties that need to know whould have the code logic to process the value of that int correctly. 

I think you are confusing the function of lower layer with application layer.  Processing of complex type happens at the "Application Layer" .  Code change is not required in the lower layer.

>  Alan DeKok.

Delivery-date: Wed, 06 Jan 2010 08:39:13 +0000
Date: Wed, 06 Jan 2010 09:38:10 +0100
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> When one receives a string that one has to parse then it requires code change - or specific code to parse the string.

  Code changes are not all the same.

> A complex attribute is no different then a string.

  What ever happened to "KISS"?

> In fact code change is required anytime one has to process any attribute beyond simply transporting the message to the next hop.  Whether  it is at the client, the proxy or the server.

 In fact, bits are exchanged when a client talks to a server, and all
bits are equal.  So DNS packets (composed of bits) are interchangeable
with RADIUS packets (composed of bits).

  Hmm... there's a logical fallacy in that argument...

> I dont understand ( i never understood) what is the objection around this!!!!

  The objection I have to your arguments is that they argue against a
position that is not reflected in the document.  They impose a false
dichotomy by treating all code changes identically.

  The document says this:  Simplicity is preferred to complexity.
Complexity is acceptable in some circumstances.  Complex changes have
higher risk than simple changes.

  There has been *major* opposition to these statements.  The push seems
to be that we should have no preference between complexity and
simplicity, because all code changes are equal, and complex systems are
no different than simple ones.

  50 years of computer science practice shows this argument to be false.

  If you have found a way to make complex changes no more expensive or
risky than simple changes, you have discovered practices that will
revolutionize computer science, and will make you personally wealthy.

  Alan DeKok.

Delivery-date: Wed, 06 Jan 2010 05:28:55 +0000
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Subject: RE: "Last Look" at the RADIUS Design Guidelines document
Date: Tue, 5 Jan 2010 21:27:39 -0800

Avi Lior said: 

"While i am at it --- what happened to getting rid of normative statements
in this informative document????"

What leads you to believe that Informational RFCs can't use normative
language?  RFC 2026 (or any other
IETF process document) contains no such prohibition. 

In any case, this is a BCP, and there is no prohibition on normative
language in BCPs either. 

On 21-12-2009, at 00:31 , Joseph Salowey (jsalowey) wrote:

> 
> 
>> -----Original Message-----
>> From: Alan DeKok [mailto:[email-masked]] 
>> Sent: Friday, December 18, 2009 11:49 PM
>> To: Joseph Salowey (jsalowey)
>> Cc: Bernard Aboba; [email-masked]
>> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
>> 
>> Joseph Salowey (jsalowey) wrote:
>>> A. Section 2.1.3
>>> 
>>> I did not find the discussion of complex attributes very compelling.
>>> Its not clear to me what the difference between string and complex 
>>> attribute is.  If your RADIUS server supports string then it seems 
>>> that it would be possible to support a complex attribute without 
>>> requiring a "code change".
>> 
>>  It depends on what you mean by "support".
>> 
>>  There is no question that a RADIUS server can *transport* 
>> any complex attribute if the attribute is treated as type 
>> "string".  However, having the RADIUS server parse that 
>> attribute requires much more work.
>> 
> [Joe] It seems a type "string" attribute would have the same parsing
> requirement.    
> 
>>  Perhaps a better argument is to ask "why?".  i.e. Why is a 
>> data structure being sent when the contents could have been 
>> broken out into separate attributes with standard data types?
>> 
> [Joe] To me it seems like you are just pushing the problem around.  If
> the RADIUS server doesn't have to validate or parse the attribute then
> it doesn't make a difference.  If the RADIUS server does need to process
> it then you need code to do the validation and parsing across several
> basic attributes.    
> 
>>  The document tries to suggest that where possible, complex 
>> attributes should be replaced by attributes with standard 
>> data types.  Where that is not possible, complex attributes 
>> could be used.
>> 
>>> B. Section 2.1.4
>>> 
>>> I'm not really sure what this section is trying to accomplish.  It 
>>> seems to be a lot about deployment guidelines instead of 
>> design guidelines.
>>> I'm also not convinced that the use of complex attributes 
>> makes things 
>>> less secure.  It does not seem this section belongs in this 
>> document.
>> 
>>  Using complex attributes does not make things less secure.  *Code
>> changes* make things less secure.
>> 
> [Joe] Complex attributes don't always require code changes and if you
> are adding several new basic attributes that need to be validated
> together then you need code to do that. 
> 
>>  The intent of this section is to explain some of the 
>> reasons behind the recommendations, rather than to have them 
>> appear out of thin air.
>> 
>>> C. Section 5
>>> 
>>> This section references section 2.1.4, however it does not 
>> seem there 
>>> is anything actionable for a protocol document to do with 
>> section 2.1.4.
>> 
>>  I think the reference should be to 2.1.3.
>> 
> [Joe] OK, I think that makes more sense. 
> 
>>> D. Section A.2.2
>>> 
>>> Since I did not agree with the motivation for section 
>> 2.1.3, I don't 
>>> find this section compelling.
>> 
>>  This is one point where I strongly disagree.  It can be 
>> summarized as "keep things simple".
>> 
>>  Would you counter this section by suggesting it's a *good* 
>> idea to have complex attributes, where standard ones would do 
>> just as well?  If so, why?
>> 
> [Joe] That does not seem to be what section A.2.2 states.  It talks
> about whether attributes need dynamic computation or not.  It seems the
> second and third bullet outlaw all cases, since the first covers dynamic
> computation and the second covers static attributes.  
> 
>>> E. Section A.2.1
>>> 
>>> I don't see how defining a polymorphic attribute as multiple 
>>> attributes helps.  I'm probably missing something, do you 
>> have an example?
>> 
>> See Section 3.2 for a larger explanation.  In short:
>> 
>> - Attribute X means "integer", unless there is another 
>> attribute Y in the packet, in which case Attribute X means 
>> "mac address"
>> 
>>  Both the size and contents of the attribute changes.  
>> There's really no good reason.  Instead, two standard 
>> attributes can be used, with no magical meanings.
>> 
> [Joe] OK, got it. 
> 
>>  Alan DeKok.
>> 
> 
> --

Delivery-date: Wed, 06 Jan 2010 04:10:25 +0000
From: Avi Lior <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 5 Jan 2010 23:09:14 -0500
Subject: Re: "Last Look" at the RADIUS Design Guidelines document
Accept-Language: en-US
acceptlanguage: en-US

I agree with Joe.

When one receives a string that one has to parse then it requires code change - or specific code to parse the string.

A complex attribute is no different then a string.

In fact code change is required anytime one has to process any attribute beyond simply transporting the message to the next hop.  Whether  it is at the client, the proxy or the server.

I dont understand ( i never understood) what is the objection around this!!!!

While i am at it --- what happened to getting rid of normative statements in this informative document????

On 21-12-2009, at 00:31 , Joseph Salowey (jsalowey) wrote:

> 
> 
>> -----Original Message-----
>> From: Alan DeKok [mailto:[email-masked]] 
>> Sent: Friday, December 18, 2009 11:49 PM
>> To: Joseph Salowey (jsalowey)
>> Cc: Bernard Aboba; [email-masked]
>> Subject: Re: "Last Look" at the RADIUS Design Guidelines document
>> 
>> Joseph Salowey (jsalowey) wrote:
>>> A. Section 2.1.3
>>> 
>>> I did not find the discussion of complex attributes very compelling.
>>> Its not clear to me what the difference between string and complex 
>>> attribute is.  If your RADIUS server supports string then it seems 
>>> that it would be possible to support a complex attribute without 
>>> requiring a "code change".
>> 
>>  It depends on what you mean by "support".
>> 
>>  There is no question that a RADIUS server can *transport* 
>> any complex attribute if the attribute is treated as type 
>> "string".  However, having the RADIUS server parse that 
>> attribute requires much more work.
>> 
> [Joe] It seems a type "string" attribute would have the same parsing
> requirement.    
> 
>>  Perhaps a better argument is to ask "why?".  i.e. Why is a 
>> data structure being sent when the contents could have been 
>> broken out into separate attributes with standard data types?
>> 
> [Joe] To me it seems like you are just pushing the problem around.  If
> the RADIUS server doesn't have to validate or parse the attribute then
> it doesn't make a difference.  If the RADIUS server does need to process
> it then you need code to do the validation and parsing across several
> basic attributes.    
> 
>>  The document tries to suggest that where possible, complex 
>> attributes should be replaced by attributes with standard 
>> data types.  Where that is not possible, complex attributes 
>> could be used.
>> 
>>> B. Section 2.1.4
>>> 
>>> I'm not really sure what this section is trying to accomplish.  It 
>>> seems to be a lot about deployment guidelines instead of 
>> design guidelines.
>>> I'm also not convinced that the use of complex attributes 
>> makes things 
>>> less secure.  It does not seem this section belongs in this 
>> document.
>> 
>>  Using complex attributes does not make things less secure.  *Code
>> changes* make things less secure.
>> 
> [Joe] Complex attributes don't always require code changes and if you
> are adding several new basic attributes that need to be validated
> together then you need code to do that. 
> 
>>  The intent of this section is to explain some of the 
>> reasons behind the recommendations, rather than to have them 
>> appear out of thin air.
>> 
>>> C. Section 5
>>> 
>>> This section references section 2.1.4, however it does not 
>> seem there 
>>> is anything actionable for a protocol document to do with 
>> section 2.1.4.
>> 
>>  I think the reference should be to 2.1.3.
>> 
> [Joe] OK, I think that makes more sense. 
> 
>>> D. Section A.2.2
>>> 
>>> Since I did not agree with the motivation for section 
>> 2.1.3, I don't 
>>> find this section compelling.
>> 
>>  This is one point where I strongly disagree.  It can be 
>> summarized as "keep things simple".
>> 
>>  Would you counter this section by suggesting it's a *good* 
>> idea to have complex attributes, where standard ones would do 
>> just as well?  If so, why?
>> 
> [Joe] That does not seem to be what section A.2.2 states.  It talks
> about whether attributes need dynamic computation or not.  It seems the
> second and third bullet outlaw all cases, since the first covers dynamic
> computation and the second covers static attributes.  
> 
>>> E. Section A.2.1
>>> 
>>> I don't see how defining a polymorphic attribute as multiple 
>>> attributes helps.  I'm probably missing something, do you 
>> have an example?
>> 
>> See Section 3.2 for a larger explanation.  In short:
>> 
>> - Attribute X means "integer", unless there is another 
>> attribute Y in the packet, in which case Attribute X means 
>> "mac address"
>> 
>>  Both the size and contents of the attribute changes.  
>> There's really no good reason.  Instead, two standard 
>> attributes can be used, with no magical meanings.
>> 
> [Joe] OK, got it. 
> 
>>  Alan DeKok.
>> 
> 
> --