In Issue 325 (see http://aboba.drizzlehosting.com/RADEXT/radissues3.html#Issue%20325) , Joe pointed out a number of
issues within the Design Guidelines document Sections 2.1.3, 2.1.4, 5, A2.1 and A2.2.
The comments on Sections 5 and A.2.1 relate to the clarity of those sections, which presumably can be addressed by appropriate edits,
so I will not dwell on those aspects.
Instead I will focus on the comments on Sections 2.1.3, 2.1.4 and A 2.2, which relate to complex attributes. Those Sections
have garnered considerable discussion on the list, much of it “frank” (to use a diplomatic phrase).
With respect to complex attributes, my interpretation of the list discussion is that Sections 2.1.3, 2.1.4 and A 2.2 should be revised.
IMHO, improvements could be made in some of the following aspects of the current text:
a. Clearer articulation of the current situation. As noted in Joe’s original posting, not all uses of complex attributes (such as
sending of a complex attribute from server to client) require code changes on the server, and the need for code changes
differ considering whether we are talking about the client or server side, or whether the attribute is being sent or received.
My personal take is that Section 2.1.3 could do with some restructuring to better articulate the implications of each scenario (see
http://ops.ietf.org/lists/radiusext/2009/msg00665.html for details).
b. More detailed look at security issues. Section 2.1.4 addresses the potential security vulnerabilities of complex attributes.
However, since RADIUS has been around a while, we have concrete data relating to the types of issues that tend to result
in major security problems (e.g. see http://securityvulns.com/advisories/radius.asp ), such as buffer overflows. Looking
at the past incidents, it is not clear to me that all “complex” attributes would be equally likely to exhibit these problems.
For example, it would seem to me that a “complex” attribute of fixed length would be less likely to be vulnerable to a buffer
overflow than one that involved variable length, particularly if this was combined with polymorphism and/or nesting.
c. Additional considerations. As noted in the Appendix, complex RADIUS attributes have been used in the past, so
that in those cases their merit was thought to outweigh the disadvantages. While A 2.2 does provide considerations
useful for the evaluation of a “complex” attribute design, it is not clear to me that all the useful elements of a potential
checklist have been taken into account. For example, looking back at RFC 5090, the decision was made to break up
a “complex” String attribute into 20 separate attributes. Given the number of additional attributes that were
consumed as well as the effort required to parse each of these 20 attributes, did this decision really generate
benefits in excess of the costs? In retrospect, the argument does not seem like a slam dunk.