Re: [secdir] draft-zorn-radius-pkmv1-05.txt

["Glen Zorn" <[e-mail]>]

Donald Eastlake [mailto:[e-mail]] 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.

...