d(_dot_)b(_dot_)nelson(_at_)comcast(_dot_)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".
This statement puzzles me: section 2.1.3 of the design guidelines document
says:
As can be seen in Appendix B, most of the existing complex attributes
involve authentication or security functionality. Supporting this
functionality requires code changes on both the RADIUS client and
server, regardless of the attribute format. As a result, in most
cases, the use of complex attributes to represent these methods is
acceptable, and does not create additional interoperability or
deployment issues.
But none of the Attributes mentioned in Appendix B have anything to do with
RADIUS security as I understand it. Can you explain?
The guidelines
document could be updated to address this.
RADIUS could transport parameters for *another* protocol.
Like EAP?
Those
attributes are not security related.
I see. What attributes (besides Message-Authenticator) are related to
RADIUS security?
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.
Alan DeKok.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf