Subject: [radext] #130: Dan's Review

From: "radext issue tracker" <[email-masked]>
Date: Fri, 02 Nov 2012 23:41:17 -0000

#130: Dan's Review

 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.

-- 
-----------------------------+-----------------------------
 Reporter:  dharkins@…       |      Owner:  bernard_aboba@…
     Type:  defect           |     Status:  new
 Priority:  major            |  Milestone:  milestone1
Component:  ieee802ext       |    Version:  1.0
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+-----------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/130>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Fri, 02 Nov 2012 23:59:16 -0000

#130: Dan's Review

Comment (by bernard_aboba@…):

 [BA]

 Section 2.2

 I believe that IEEE 802.1X-2010 requires the EAP-Key-Name attribute to
 calculate the encryption keys on a wired network, so that presumably
 without it the key agreement exchange will fail.

 Sections 2.3 - 2.4.  I don't know of anything bad that will happen in any
 existing access technology if these attributes aren't returned by the
 RADIUS server.

 Section 2.9

 I get your point.  Crashing if an umlaut is included in the SSID is
 probably not an alternative ;)

 Sections 2.15-2.18

 I agree that these attributes are more for "reporting" in an Access or
 Accounting-Request than something that would be used by a RADIUS server to
 make an access decision. Feel free to suggest text to make that clear.

 Security considerations.

-- 
-----------------------------+------------------------------
 Reporter:  dharkins@…       |       Owner:  bernard_aboba@…
     Type:  defect           |      Status:  new
 Priority:  major            |   Milestone:  milestone1
Component:  ieee802ext       |     Version:  1.0
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/130#comment:1>
radext <http://tools.ietf.org/radext/>