|
> I believe the intent was "related to RADIUS security". The guidelines > document could be updated to address this. The rationale behind the original exemption was that security required changes on both the RADIUS client and server. Therefore the RADIUS server would need a code change anyway, regardless of whether the attributes were complex or simple. That rationale applies not just to "RADIUS security" but also to authentication mechanisms, many of which were previously implemented with complex attributes (e.g. CHAP). So I'm not clear that we're talking about a "loophole" here. > encapsulation using RFC 2548 MPPE-Key attributes... I was unclear about how this is supposed to work. Is the idea to apply the MPPE-Key encryption mechanism to the attribute specified in the draft, or is the idea to actually use the MPPE-Key attributes themselves? If the former, more detail should be provided. If the latter, is it necessary to define two attribute formats or would it be simpler to go with one? If the RFC 2548 MPPE-Key attributes are used, is the format the same as that defined in RFC 2548 (just a wrapped key) or is the wrapping applied to a complex attribute? > a four octet Integer should be used instead of a two octet data type > (which doesn't exist in RADIUS) As I recall, the security exemption didn't apply to creation of new RADIUS data types, correct? |
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf