Subject: [radext] comments on draft-ietf-radext-ieee802ext

From: "Dan Harkins" <[email-masked]>
Date: Fri, 2 Nov 2012 15:48:47 -0700 (PDT)

Hello,

  The chairman of the IEEE 802.11 WG received a request to review this
draft; I have done just that. I hope these comments aren't too late.

1. comments on specific sections

section 2.1

  - suggest making that the ":" delimiter exist even when no MAC
    address is added. Make the example be ":AP1". This will make
    for easier parsing.

section 2.2, 2.3 and 2.4

  - what does the NAS do if it requested the attr but didn't
    get one? I presume nothing but if there are guidelines on
    the NAS putting the attr in a Request then there should be
    guidelines on what to do when it gets back in an Accept
    that doesn't have it. What does a NAS do if it gets one
    when when it didn't ask for one?

section 2.3

  - how are mutliple names demarked? Should there be a sub-structure
    or a delimiter (which cannot be part of the EAP-Peer-Id)?

section 2.9

  - what does a non-robust implemention do? What's wrong with
    just saying that "an implementation SHOULD..." or even "an
    implementation MUST support the field as undistinguished
    octets"? If it's a SHOULD then explain the conditions under
    which an implementation can legitimately not treat them
    that way.

section 2.12

  - I am unwilling to pay 44 swiss francs to get ISO-14962-1997
    to figure this out for myself, so how is a string encoded
    by that standard? Is there a length indication in the
    encodng to allow for multiple languages to be properly
    demarked and parsed? If not then I think there needs to
    be some delimiter between them.

secton 2.15, 2.16 and 2.17

  - what is a server supposed to do with this information?
    Reject the authentication because it used a different
    cipher/AKM suite?

section 2.18

  - where is "table ?" in IEEE 802.11-2012?

2. misc. comments

  - I question the validity of using ciphersuite information
    and RF band to decide whether to accept/deny an
    authentication. If the AP is beaconing out support for a
    cipher that is not acceptable for RADIUS authentication
    by any user then it indicates a configuration error on
    the AP. Why on earth would one prohibit a user from a
    certain band that the AP is operating in? I think there
    should be some text around the utility of these attrs.

  - If you're gonna limit/prohibit people to/from "TV white
    space" then what channels in that space? Again, why?

  - The security considerations are pretty weak. Which of
    these new attributes need channel binding? What are
    the implications of not doing channel bindings with
    these attributes?

  regards,

  Dan.