Subject: [radext] Additional 802.11 attributes

From: Joe Salowey <[email-masked]>
Date: Tue, 8 May 2012 14:09:51 -0700

I've received a few off list suggestions for additional RADIUS attributes to add to RADIUS Attributes for IEEE 802 Networks.  These include

1.   WLAN-Reason-Code  - used to transmit the reason for authentication failure from AAA to AP in an Access-Reject.  The code is included in reason code of a Disassociation or De-authentication Frame
2.   WLAN-Pairwise-Cipher - communicates the negotiated pairwise cipher from the AP to the AAA.
3.  WLAN-Group-Cipher - communicates the negotiated group cipher from the AP to the AAA. 
4.  WLAN-AKM-Suite - contains information on the authentication and key management suite negotiated buy the AP. 
5.  WLAN-RF-Band - contains information on the RF band used by the AP.  

Below is suggested text for these attributes from Dave Stephenson:

Thanks,

Joe
 
2.9.  WLAN-Reason-Code
 
Description
 
The WLAN-Reason-Code Attribute contains information on the reason for authorization failure subsequent to a mobile device’s authentication request towards a Wi-Fi access network.
 
A WLAN-Reason-Code Attribute MAY be included within an Access-Reject or Disconnect-Request packet.  Upon receipt of an Access-Reject packet, the WLAN-Reason-Code value is copied by the Authenticator / AP into the Reason code field of a Disassociation or Deauthentication frame (see clause 8.3.3.4 and 8.3.3.12 respectively in IEEE 802.11-2012), which is subsequently transmitted to the Supplicant / mobile device.  A summary of the WLAN-Reason-Code Attribute format is shown below.  The fields are transmitted from left to right.
 
  0                   1                   2                   3 
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |  Length       |             Value             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Code
 tbd8
 
Length
 =2
 
Value
The Value field is two octets containing a 16-bit unsigned integer drawn from Table 8-36 in clause 8.4.1.7 of IEEE 802.11-2012.  The value’s least significant octet is contained in bits 23-16 and most significant octet in bits 31-24 (network octet order).  Note: not all reason codes defined in the Table 8-36 are expected to be used by an AS.
 
[Note]: the importance of including this attribute is for authentication and authorization of mobile devices in public Wi-Fi access; it is important to inform the mobile when authorization is denied, even though authentication may have been successful.  This can occur for AS policy reasons or for reasons related to the user’s subscription.  The following Reason codes for public Wi-Fi access networks were added by the IEEE 802.11u-2011 amendment:
 
Reason
 Code
 Value   Description
27      Disassociated because session terminated by SP request
28      Disassociated because of lack of SP roaming agreement
29      Requested service rejected because of SP cipher suite or AKM requirement
30      Requested service not authorized in this location

 
2.10.  WLAN-Pairwise-Cipher
 
Description
 
The WLAN-Pairwise-Cipher Attribute contains information on the pairwise cipher suite used to establish the robust security network association (RSNA) between the AP and mobile device.
 
A WLAN-Pairwise-Cipher Attribute SHOULD be included within an Access-Request packet.  A summary of the WLAN-Pairwise-Cipher Attribute format is shown below.  The fields are transmitted from left to right.
 
  0                   1                   2                   3 
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |  Length       |             Value              
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Value                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Code
 tbd9
 
Length
 =4
 
Value
The Value field is four octets formatted in accordance with Figure 8-187 with values drawn from Table 8-99 of IEEE 802.11-2012.

 
2.11.  WLAN-Group-Cipher
 
Description
 
The WLAN-Group-Cipher Attribute contains information on the group cipher suite used to establish the robust security network association (RSNA) between the AP and mobile device.
 
A WLAN-Group-Cipher Attribute SHOULD be included within an Access-Request packet.  A summary of the WLAN-Group-Cipher Attribute format is shown below.  The fields are transmitted from left to right.
 
  0                   1                   2                   3 
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |  Length       |             Value              
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Value                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Code
 tbd10
 
Length
 =4
 
Value
The Value field is four octets formatted in accordance with Figure 8-187 with values drawn from Table 8-99 of IEEE 802.11-2012.

 
2.12.  WLAN-AKM-Suite
 
Description
 
The WLAN-AKM-Suite Attribute contains information on the authentication and key management suite used to establish the robust security network association (RSNA) between the AP and mobile device.
 
A WLAN-AKM-Suite Attribute SHOULD be included within an Access-Request packet.  A summary of the WLAN-AKM-Suite Attribute format is shown below.  The fields are transmitted from left to right.
 
  0                   1                   2                   3 
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |  Length       |             Value             
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Value                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Code
 tbd11
 
Length
 =4
 
Value
The Value field is four octets formatted in accordance with Figure 8-187 with values drawn from Table 8-101 of IEEE 802.11-2012.

 
2.12.  WLAN-RF-Band
 
Description
 
The WLAN-RF-Band Attribute contains information on the RF band used by the AP for transmission and reception of information to and from the mobile device.  This information can be used, for example, to provide a relative quality of experience indication for the mobile device’s user (i.e., some RF bands have more interference than others).
 
A WLAN-RF-Band Attribute SHOULD be included within an Access-Request packet.  A summary of the WLAN-RF-Band Attribute format is shown below.  The fields are transmitted from left to right.
 
  0                   1                   2                   3 
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |  Length       |     Value     |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Code
 tbd12
 
Length
 =2
 
Value
The Value field is 1 octet having a value chosen from the table below:
Band ID value     Meaning
      0           TV white spaces
      1           Sub-1 GHz (excluding TV white spaces)
      2           2.4 GHz
      3           3.6 GHz
      4           4.9 and 5 GHz
      5           60 GHz
      6-255       Reserved

[Note]: this table was copied from IEEE 802.11ad-d5.  I’m not sure of the relative publication dates of this internet draft and IEEE 802.11ad-d5.  Since it’s generally not recommended to reference a draft specification in an RFC, I’ve copied the table.  If we discover that the IEEE document will be published in time, then we could deleted the table and instead reference Table 8-53a in IEEE 802.11ad.

---

From: Jouni Malinen <[email-masked]>
Date: Wed, 9 May 2012 01:35:21 +0300

> A summary of the WLAN-Reason-Code Attribute format is shown below.  The fields are transmitted from left to right.
>  
>   0                   1                   2                   3 

> The Value field is two octets containing a 16-bit unsigned integer drawn from Table 8-36 in clause 8.4.1.7 of IEEE 802.11-2012.  The value’s least significant octet is contained in bits 23-16 and m…

Hmm.. Is this really suggesting a RADIUS attribute that is using little
endian byte order? Aren't pretty pretty much all other RADIUS attributes
defined using big endian byte order? While I can understand that this
comes from the IEEE 802.11 side where the Reason Code is indeed little
endian, this type of difference between RADIUS attributes is just asking
for issues..

> [Note]: the importance of including this attribute is for authentication and authorization of mobile devices in public Wi-Fi access; it is important to inform the mobile when authorization is denie…

That IEEE 802.11u-2011 reference should be replaced with a reference to
IEEE Std 802.11-2012.

> 30      Requested service not authorized in this location

Is Reason Code the best place for sending this information? It is a bit
difficult to extend this with any new potentially needed value while
something like EAP notifications could be work better for this.

> A WLAN-Pairwise-Cipher Attribute SHOULD be included within an Access-Request packet.  A summary of the WLAN-Pairwise-Cipher Attribute format is shown below.  The fields are transmitted from left to…

Is there some general text pointing out that these attributes are
applicable only for the case of IEEE 802.11 networks? This SHOULD
statement could be interpreted as a strong recommendation for any NAS to
include the attribute while it should really only apply to the case
where the connection is an IEEE 802.11 RSNA.

> The WLAN-Group-Cipher Attribute contains information on the group cipher suite used to establish the robust security network association (RSNA) between the AP and mobile device.

If we are adding this, we could as well add WLAN-Group-Mgmt-Cipher from
IEEE 802.11w (now in IEEE Std 802.11-2012) to cover the case of
protected management frames. Though, this would also need another
attribute to indicate whether the station negotiated use of the
mechanism.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Jouni Malinen <[email-masked]>
Date: Wed, 9 May 2012 01:35:21 +0300

-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: <[email-masked]>
Date: Wed, 9 May 2012 03:06:31 +0200

Here are some questions/comments on these proposed attributes.

Regards,

Lionel

2.9.  WLAN-Reason-Code
 
[Lionel] what about reusing Message-Reply attribute in Access-Reject and
define additional values for Acct-Terminate-Cause used in
Disconnect-Reject (as described in
http://tools.ietf.org/html/rfc3580#section-2.1) ?   

[Lionel] If my understanding is correct, it is expected that the AAA
server could reject the access authorization request based on these
attributes describing the existing RSNA between the AP and mobile node.
If the resulting RSNA is not suitable for the SP, I'm not sure if that
this is something that should/could be managed per user authorization
request but rather via local policies or SLA between partners.  

2.12.  WLAN-RF-Band
 
The WLAN-RF-Band Attribute contains information on the RF band used by
the AP for transmission and reception of information to and from the
mobile device.  This information can be used, for example, to provide a
relative quality of experience indication for the mobile device's user
(i.e., some RF bands have more interference than others).

[Lionel] if it is an indication for the user, why is it intended to
provide this information to the AAA server?

---

From: <[email-masked]>
Date: Wed, 9 May 2012 03:06:31 +0200

Regards,

Lionel

2.9.  WLAN-Reason-Code

2.12.  WLAN-RF-Band

---

From: Joe Salowey <[email-masked]>
Date: Mon, 14 May 2012 13:02:08 -0700

Hi Jouni,

Thanks for the comments.   Response inline below.

Cheers,

Joe

> endian, this type of difference between RADIUS attributes is just asking

[Joe]   I think I agree that we need to be specific about the byte order and I agree that we should be using big-endian order. 

> something like EAP notifications could be work better for this.

[Joe]  I think there is a tradeoff here.  THere is a field already defined for this in 802.11 that can be extended with existing error codes.  These error codes are can be used by the mobile in whatever way it fits.    EAP notifications are limited to text strings for display which limits how the mobile can use them and introduces language and encoding issues.    

> where the connection is an IEEE 802.11 RSNA.

[Joe] Good point. 

> attribute to indicate whether the station negotiated use of the

[Joe] We can add this.  Why couldn't the presence of the attribute be used to indicate that the station negotiated use of the mechanism?

---

From: Joe Salowey <[email-masked]>
Date: Mon, 14 May 2012 13:02:08 -0700

Hi Jouni,

Cheers,

Joe

[Joe] Good point.

---

From: Joe Salowey <[email-masked]>
Date: Mon, 14 May 2012 13:13:55 -0700

Hi Lionel,

Thanks for the quick review, responses below.

Cheers,

Joe

> http://tools.ietf.org/html/rfc3580#section-2.1) ?   

[Joe]  We could overload the message-reply attribute, but we would need to define how to map the text in the message-reply attribute into the 802.11 response.  It seemed better to use a new attribute for this.  

> request but rather via local policies or SLA between partners.  

[Joe]  I think this information would be useful for both enterprise and SP AAA.   I think that you are correct that in many cases the policy would not be varied on a per user basis,   Even if per-user authorization is not used, it is still useful to know what ciphers are negotiated for auditing and channel bindings.

> provide this information to the AAA server?

[Joe] Good question.  I think that text is erroneous and should be removed.

---

From: Joe Salowey <[email-masked]>
Date: Mon, 14 May 2012 13:13:55 -0700

Hi Lionel,

Cheers,

Joe

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 14 May 2012 16:49:55 -0400

> [Joe] We can add this.  Why couldn't the presence of the attribute be used to indicate that the station negotiated use of the mechanism?

It could. Though, it would be a bit confusing in this particular case
since the group management cipher suite is an attribute of the BSS (AP
configuration) while the negotiation here is referring to whether the
station negotiated to use management frame protection during
association.

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 14 May 2012 16:49:55 -0400

---

From: jouni korhonen <[email-masked]>
Date: Tue, 15 May 2012 01:29:07 +0300

Jouni had a question regarding the SSID encoding:
	http://www.ietf.org/mail-archive/web/radext/current/msg07538.html

Do you think we need to indicate the SSID encoding?

- the other Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 15 May 2012 01:29:07 +0300

- the other Jouni