I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments.
This document defines seven RADIUS Attributes to support the implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management version 1). I would guess that RADIUS can be used between the 802.16 Base Station and an authorization server but I don't know how you could tell. Maybe I missed it but it looks like the RADIUS protocol isn't mentioned anywhere in 802.16-2004. From the text in some of these RADIUS attribute descriptions, it appears that they are not used between the Subscriber Station and the Base Stations but may be the basis of 802.16 Attributes that are used on that hop. Given this, I think a paragraph is needed (maybe even accompanied by a little ASCII art) at the beginning show what's going on would be useful. Many document have security considerations section that only refer to other documents and may be missing specifics to the document contents. I think this document has the opposite problem good security specifics in the security consideration section but could usefully add references to the 802.16-2004 and RADiUS security sections. The security considerations section rightly warns to protect against modification of the PKM-Auth-Key attribute. But is it really clear there is no problem with modification of the Security Association ID attribute or the attribute listing cryptosuites? The wording in Sections 3.1 and 3.2 see to almost be designed to allow the possibility of the multiple *-Cert Attributes carrying a certificate to appear in more than one Access-Request message. But I would assume that's not meaningful and/or was not intended to allow that. The table of attributes in Section 4 that gives the number of times each attribute can occur in different message types seems to have problems. Since there is no key giving it another meaning, I assume "0-1" means zero or one. But PKM-SS-Cert and PKM-CA-Cert are described and possibly occurring multiple times due to fragmentation of certificates. If the table is supposed to be in terms of logical attributes so that multiple PKM-SS-Cert attributes only count as one if they have parts of one certificate, then the table should say so. On the other hand, the PKM-SA-Descriptor attribute is shown as "0+", which presumably means zero or more, but the text description in 3.6 clearly says it can occur one or more times, which presumably would be written "1+". This whole table need to be carefully checked, the inconsistencies resolved, and it should be clear if literal binary attributes or some sort of logical aggregate attributes (in the case of the "Cert" attributes at least), is being counted. The text between the Section 6. header line and the Section 6.1 header line as well as the Section 6.1 header line itself seem superfluous and can be deleted. I think this document still needs a little more work. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
