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
 d3e3e3 at gmail.com