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