Subject: Re: "Last Look" at the RADIUS Design Guidelines document

From: Avi Lior <[email-masked]>
Date: Tue, 5 Jan 2010 23:09:14 -0500

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

--
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: 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.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 06 Jan 2010 09:38:10 +0100

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

---

From: Avi Lior <[email-masked]>
Date: Wed, 6 Jan 2010 09:27:41 -0500

I want to start with this point first...

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

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

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

>  Code changes are not all the same.
I dont even know how to respond to that.
>  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.

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 06 Jan 2010 15:57:45 +0100

> 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 applic…

  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 RAD…

  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.

---

From: Avi Lior <[email-masked]>
Date: Wed, 6 Jan 2010 14:05:47 -0500

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

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

---

From: Avi Lior <[email-masked]>
Date: Wed, 6 Jan 2010 14:28:51 -0500

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.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 06 Jan 2010 21:54:24 +0100

> 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 deb…

  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.

>    parsing functionality, although in some cases the attributes in the"

  Hmm... I'll check the revision control to see what happened to that.

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

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

> 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 wo…

  Hmm... it might not be perfect, but it does make some kind of sense.
I welcome suggestions for replacement text.

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 6 Jan 2010 14:24:55 -0800 (PST)

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

With this, I think that Radext is going to become the WG (possibly the only one) that does not care about SDOs.

Regards,

Behcet

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 7 Jan 2010 13:54:42 -0800

> Sent: Monday, December 21, 2009 12:19 AM
> To: Bernard Aboba
> Cc: Joseph Salowey (jsalowey); [email-masked]
> 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.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 7 Jan 2010 17:19:12 -0500

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

---

From: Alan DeKok <[email-masked]>
Date: Sat, 09 Jan 2010 13:47:39 +0100

> 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".

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

  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

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

---

From: Avi Lior <[email-masked]>
Date: Sun, 10 Jan 2010 00:01:52 -0500

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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Jan 2010 11:41:39 +0100

Avi Lior wrote:
> 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.
...
>    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.

---

From: "Dave Nelson" <[email-masked]>
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>

---

From: Avi Lior <[email-masked]>
Date: Sun, 10 Jan 2010 10:00:08 -0500

See inline

>  Again, the logical fallacy of "change is change, so all change has the
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...

> same risk as complex ones.  This isn't true, and the existing text does
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.

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

> document.  There's no compelling reason to keep it in the main body of

Great.

---

From: Avi Lior <[email-masked]>
Date: Sun, 10 Jan 2010 10:53:31 -0500

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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 10 Jan 2010 18:39:01 +0100

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

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

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

  You can't re-define it.

  Alan DeKok.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 11 Jan 2010 11:02:17 +0100

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Jan 2010 12:05:06 +0100

Wojciech Dec (wdec) wrote:
> 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

  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.

---

From: "Dave Nelson" <[email-masked]>
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.

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Jan 2010 07:23:26 -0800 (PST)

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
> > archive: 
> archive:

---

From: Avi Lior <[email-masked]>
Date: Mon, 11 Jan 2010 14:16:48 -0500

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.

---

From: Avi Lior <[email-masked]>
Date: Mon, 11 Jan 2010 14:44:19 -0500

David,

This document and the topics around this document have been problematic from day one as you say and its not just complex attributes.
> 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.

---

From: "David B. Nelson" <[email-masked]>
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.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Jan 2010 22:21:55 +0100

Avi Lior wrote:
> 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 ty…

  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…

  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…

  Already addressed.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Mon, 11 Jan 2010 22:03:41 -0500

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

> the RADIUS Extended Attributes document.
Well, remove the offending text in the guideline.

> 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'm certainly not suggesting that you (or anyone) ignore the document.
Not ignore "...but channel that energy elsewhere".  Same difference no?

> the standard process seriously.
Good. So I am taking the process seriously and i am seriously wanting to fix these issues.

> "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.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Jan 2010 04:50:17 +0100

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.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 12 Jan 2010 13:41:30 +0100

> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: 11 January 2010 21:21
> 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.
> 
>  > 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.
> 
> 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.
> 
> 
> --

---

From: Avi Lior <[email-masked]>
Date: Tue, 12 Jan 2010 07:38:37 -0500

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.

---

From: "Dave Nelson" <[email-masked]>
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.

---

From: Avi Lior <[email-masked]>
Date: Tue, 12 Jan 2010 10:14:06 -0500

Please see inline...

> use in "traditional" RADIUS attributes.  The logic is sound, even if you

If you really really want to get on with it then you dont need to make comments about my use of the word "Bad".

> 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

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.

---

From: "David B. Nelson" <[email-masked]>
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.

---

From: Avi Lior <[email-masked]>
Date: Tue, 12 Jan 2010 11:44:48 -0500

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

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

> 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  
Are you saying that using a String attribute to carry more then one information element is NOT a complex type.  

> 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

---

From: Avi Lior <[email-masked]>
Date: Tue, 12 Jan 2010 11:50:18 -0500

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

---

From: "David B. Nelson" <[email-masked]>
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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Jan 2010 08:50:25 +0100

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

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

---

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jan 2010 05:49:40 -0500

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

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

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

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.

> (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.

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

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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Jan 2010 12:11:19 +0100

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

> 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 ha…

  I have responded to this point many times already.

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

> 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 traditio…

  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…

  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".

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

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

---

From: "Dave Nelson" <[email-masked]>
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).

---

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jan 2010 09:59:11 -0500

I absolutely agree. 

Historically, specifically around this document  -- consensus has not been a working group priority.

---

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jan 2010 09:56:55 -0500

>  As I have said repeatedly, the document addresses the capabilities of

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.
Again it does not.

>  I have responded to this point many times already.
And we have been questioning your response many times. 

> messages for my attitude.
But it requires code change in the server.
>  Today, this is still true.
Yes but partly whereas in the past it was exclusively true.

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

> the 60% case?  Is that what you really meant to say?

No and I think you know that. 

>  Asked and answered.  No amount of repeating the question will change
You are right and the rest of us are wrong.
> 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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Jan 2010 16:20:19 +0100

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

> You are right and the rest of us are wrong.

  I'm tilting at windmills.

> 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 n…

  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.

---

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jan 2010 10:46:34 -0500

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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Jan 2010 17:16:28 +0100

> But section 2.1.3 does not reflect that model.  At *that* is the problem.

  I disagree.

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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Jan 2010 17:22:59 +0100

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

---

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jan 2010 11:34:41 -0500

> adding application layers.

Or new code perhaps.  No?

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

---

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jan 2010 13:36:18 -0500

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?

---

From: Alan DeKok <[email-masked]>
Date: Sat, 16 Jan 2010 16:31:19 +0100

>> adding application layers.

  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.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 16 Jan 2010 16:28:11 +0100

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

---

From: Avi Lior <[email-masked]>
Date: Sun, 17 Jan 2010 03:48:24 -0500

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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 17 Jan 2010 11:54:42 +0100

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…

  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.