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

From: "radext issue tracker" <[email-masked]>
Date: Thu, 21 Feb 2013 01:39:31 -0000

#130: Dan's Review

Comment (by [email-masked]):

 I have added the following paragraphs to the Security Considerations
 section:

    While it is possible for a RADIUS server to make decisions on whether
    to Accept or Reject an Access-Request based on the values of the
    WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group-
    Mgmt-Cipher and WLAN-RF-Band Attributes the value of doing this is
    limited.  In general, an Access-Reject should not be necessary,
    except where Access Points and Stations are misconfigured so as to
    enable connections to be made with unacceptable values.  Rather than
    rejecting access on an ongoing basis, users would be better served by
    fixing the misconfiguration.

    Where access does need to be rejected, the user should be provided
    with an indication of why the problem has occurred, or else they are
    likely to become frustrated.  For example, if the values of the WLAN-
    Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite or WLAN-Group-
    Mgmt-Cipher Attributes included in the Access-Request are not
    acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute
    with a value of 29 (Requested service rejected because of service
    provider cipher suite or AKM requirement) SHOULD be returned in the
    Access-Reject.  Similarly, if the value of the WLAN-RF-Band Attribute
    included in the Access-Request is not acceptable to the RADIUS
    server, then a WLAN-Reason-Code Attribute with a value of 11
    (Disassociated because the information in the Supported Channels
    element is unacceptable) SHOULD be returned in the Access-Reject.

-- 
---------------------------------+----------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     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:2>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 21 Feb 2013 01:39:47 -0000

#130: Dan's Review

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
---------------------------------+----------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect               |      Status:  closed
 Priority:  major                |   Milestone:  milestone1
Component:  ieee802ext           |     Version:  1.0
 Severity:  In WG Last Call      |  Resolution:  fixed
 Keywords:                       |
---------------------------------+----------------------------------------

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

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2013 14:26:58 -0000

#130: Dan's Review

 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.

 [BA] Done.

 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?

 [BA] Text now says that the NAS ignores the attribute if it didn't ask for
 it.  When one is requested and it isn't returned, the Access-Accept is
 treated as an Access-Reject.

 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)?

 [BA] Only one name is included per attribute so there is no need for a
 sub-structure.

 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.

 [BA] Text now says MUST.

 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.

 [BA] I believe it is a three letter code, so no delimiter is needed.

 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?

 [BA] My assumption is that it is primarily for accounting purposes. While
 it could reject the authentication, that seems sub-optimal.

 section 2.18

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

 [BA] Added reference to the correct table in IEEE 802.11-2012.

     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?

 [BA] I have material to the security considerations section indicating why
 this is somewhat silly.

     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?

 [BA] Looking at these attributes, I could not find any that would be of
 value in crypto-binding.

     regards,

     Dan.

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

---

From: Mark Jones <[email-masked]>
Date: Mon, 25 Feb 2013 09:55:10 -0500

Hi Dan,

I've expanded on Bernard's response for the 802.11u AVPs.

Regards
Mark

>  conditions under which an implementation can legitimately not treat them
[mj] This was originally a “SHOULD” meaning “interpret at your own risk”.
However, the draft does not define any structure for this field so there is
no legitimate reason to parse it and I agree with tightening it to a MUST.
Rev -04 still contains the "robust" qualifier and I think that can be
deleted now.

>  [BA] I believe it is a three letter code, so no delimiter is needed.
[mj] ISO-14962-1997 essentially documents ASCII so your 44 Swiss francs
could be better spent elsewhere. 802.11u has this reference so I carried it
forward for consistency. The value encoding is also kept consistent with
802.11u to avoid requiring NAS implementations to do translations. The
value is a fixed length 3 octet field in 802.11u hence the “null” padding
required for a two character language code. This AVP contains a single
ISO-639 language code so no delimiter is required. Multiple language
support at the venue is expressed by including more than one
WLAN-Venue-Language AVP in the Access-Request.

> Ticket URL: <
> https://wiki.tools.ietf.org/wg/radext/trac/ticket/130#comment:4>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>