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

[Avi Lior <avi@bridgewatersystems.com>]

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.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>