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

[Alan DeKok <aland@deployingradius.com>]

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.

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