Submitter name: Alan DeKok
Submitter email address: aland@deployingradius.com
Date first submitted: July 24, 2009
Reference: http://ops.ietf.org/lists/radiusext/2009/msg00340.html
Document: Design Guidelines
Comment type: Technical
Priority: S
Section: A.2.1
Rationale/Explanation of issue:
Section A.2.1 states:
* Complex data structures defined only within RADIUS.
The additional functionality defined in [EXTEN] SHOULD be used
instead. This recommendation does not apply to new attributes
for authentication or security, as described below in Section
A.2.2.
Should this exemption be removed and/or clarified?
d.b.nelson@comcast.net wrote: > Yeah. I've always been a bit uncomfortable with the "security > functionality" escape clause in the RADIUS Design Guidelines draft. > Lots of things can reasonably be claimed to be "security related". I > would have preferred the exception to be crafted a bit narrower, just > for this reason. But, unless wording of Design Guidelines is changed, > you have a legitimate argument. I believe the intent was "related to RADIUS security". The guidelines document could be updated to address this. RADIUS could transport parameters for *another* protocol. Those attributes are not security related. They either follow the RADIUS data model (int, IP address, etc.), or they are "opaque data" that RADIUS is simply transporting on the behalf of the other protocol.Proposed Resolution: Discuss
Join me |