|
> B. Section 2.1.4 > > I'm not really sure what this section is trying to accomplish. It seems > to be a lot about deployment guidelines instead of design guidelines. > I'm also not convinced that the use of complex attributes makes things > less secure. It does not seem this section belongs in this document. I think this section is trying to make a point relating to the security properties of complex or opaque attributes, particularly in the case of attributes sent from the RADIUS client to server. However, it occurs to me that the security risks depend quite a bit on how the complex or opaque attribute is structured. An "opaque" attribute that contains complex structures such as ASN.1 or XML would represent a considerably larger security risk than say, a complex attribute including multiple 32-bit fields. It also occurs to me that some of the same security risks could be present in simple attributes. For example, even though a "string" attribute might be widely implemented, if an attribute incorporates a new concatenation mechanism, then such an attribute might introduce a buffer-overun vulnerability that would be unlikely to occur in the case of a complex attribute consisting of fixed fields. |