Donald Eastlake [mailto:d3e3e3(_at_)gmail(_dot_)com] writes:
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.
Sorry for the rather slow response, but I honestly didn't know what to say.
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.
Your comments seem to suggest a lack of familiarity with RFC 2865 and the
RADIUS protocol in general. Leaving aside the question of how one could
expect to usefully review a document that _extends_ a protocol w/o
understanding the protocol being extended, RADIUS is only defined between a
NAS (in this case, an 802.16 Base Station) and a RADIUS server.
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.
I'm not at all sure what 802.16 security has to do with RADIUS, but I guess
I can add a reference to RFC 2869 in the Security Considerations section.
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?
No, apparently not. I had originally thought that modifying the list of
supported cryptosuites would just result in DoS, but that's not right. I'll
fix it.
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.
There is no way to do such a thing in standard RADIUS.
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+".
The relevant text from section 3.6 says "One or more instances of the
PKM-SA-Descriptor Attribute MAY occur in an Access-Accept message." RFC
2119 says about the keyword "MAY", "This word, or the adjective "OPTIONAL",
mean that an item is truly optional"; this says to me that zero, one or more
instances of the PKM-SA-Descriptor Attribute can be in an Access-Accept
message, just in a more compact and formal way. If this is not clear,
however, I'm open to suggestions for alternate text.
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.
I can add notes to the table regarding the "logical" vs. "physical" nature
of the PKM-*-Cert Attributes, as well as a key to the meaning of "0+", etc.
Is that OK?
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.
Fine.
...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf