Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf