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

[Alan DeKok <aland@deployingradius.com>]

Joseph Salowey (jsalowey) wrote:
>>   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.    

  If the RADIUS server needs to understand it, and it carries a complex
data type.

  e.g. There are no parsing requirements for the Proxy-State attribute.
 It is a "string" attribute, but the contents are treated as an opaque
blob by proxies and clients.

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

  Partly.  The validation and parsing of the basic data types has
already been done.  Any additional validation and parsing is not needed
at the RADIUS attribute level.  Instead, it is needed to ensure that the
right set of attributes is sent and/or received.

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

  Of course.

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

  I think you have the bullet references wrong... but I understand your
point.

  However, the section is trying to say:

a) re-using existing complex types is likely OK

b) creating new complex types for security is likely OK

c) transporting complex types that can be ignored RADIUS is likely OK
   (e.g. EAP-Message)

d) If the complex type can be instead be replaced by multiple attributes
   of the basic types, this is the preferred approach

e) Anything else is likely not a good use of RADIUS

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