1. WLAN Extended Multicast for TGu
Month Year
November 2006
November 2006
WLAN Extended Multicast for TGu
Authors:
Date:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Amy Zhang et al
Amy Zhang et al

2. Month Year
November 2006
November 2006
Abstract
This document outlines a WLAN Extended Multicast proposal which suggests the multicast traffics provided by an SSPN to be isolated over the air.
An SSPN may provide more than one multicast services and we assume that each SSPN may be bound to an SSID, so the multicast traffics isolation is in an SSID.
If SSID is 1:1 mapping with BSSID, the multicast traffics shall be isolated in a BSS domain.
If multiple SSIDs are bound to a single BSSID, the multicast traffics shall be isolated in an SSID domain.
Amy Zhang et al
Amy Zhang et al

3. Agenda Why Extended Multicast Multicast Proposal General consideration
Month Year
November 2006
November 2006
Agenda
Why Extended Multicast
Multicast Proposal
General consideration
Amy Zhang et al
Amy Zhang et al

4. Why Extended multicast
November 2006
Why Extended multicast
There are many multicast services provided by an SSPN, and the multicast traffics shall be isolated over the air. A multicast frame no longer needs to be sent to all the STAs associated with an SSPN.
SSPN
AP (SSID=CCMC)
WLAN
Amy Zhang et al

5. Why multicast (Cont.) Interworking with 3G
Month Year
November 2006
November 2006
Why multicast (Cont.)
Interworking with 3G
The video multicast service is supported by the video provider of 3G (e.g. Mobile TV), and the clients are enjoying the service through the WLAN access.
The TV provider hopes that the TV stream only needs to be transferred by AP to STAs who have subscribed their service.
Video Provider
WAG
WLAN
3G Network
AP (SSID=CCMC) AS
Amy Zhang et al
Amy Zhang et al

6. Current Deployment Mechanism: Multicast-based
November 2006
Current Deployment Mechanism: Multicast-based
AP uses GTK encrypt the multicast frame, the STA can identify if the frame is for it or not by the DA in MAC header.
It seems the mainstream to deploy multicast traffic.
Use the same GTK encrypt
different multicast traffic over the air
Amy Zhang et al

7. Current Deployment Mechanism: Multicast-based (Cont.)
November 2006
Current Deployment Mechanism: Multicast-based (Cont.)
To some extend, it has some multicast segregation by DA, but there is only one GTK in a BSS no matter how many multicast groups it have in a BSS.
Any associated STAs have the GTK, so the un-intended users can decrypt and use the multicast service without paying for it.
Amy Zhang et al

8. Recommend Deployment Mechanism: Extended Multicast-based
November 2006
Recommend Deployment Mechanism: Extended Multicast-based
Using different group keys to separate the multicast traffics into different groups from the same SSPN besides DA.
Only the intended STAs can receive and decrypt the multicast traffic.
Be equal to the wired L2 multicast deployment mechanism.
The multicast traffic is only deployed to the intended ports in wired environment.
Use layer-2 group temporal key GTK1
Use layer-2 group temporal key GTK2
Amy Zhang et al

9. Agenda Why Multicast Multicast Proposal General requirement analysis
Month Year
November 2006
November 2006
Agenda
Why Multicast
Multicast Proposal
General requirement analysis
Amy Zhang et al
Amy Zhang et al

10. Extended Multicast Service Overview
November 2006
Extended Multicast Service Overview
Different groups may maintain different GTKs for encryption/ decryption.
The GTK is relative to multicast group and unicast to the STA who subscribes the multicast service when it adds to the group.
The GTK is derived and maintained by AP.
AP may determine whether send the GTK to a STA or not according to the STA’s subscription information( multicast service subscription information).
STAs can identify whether the multicast frame is for it and use the correct GTK do the decryption according to the DA in the MAC header.
Amy Zhang et al

11. Multicast Operation November 2006
STAs discover the Extended Multicast Capability via the Multicast Capability bit included in the Beacon and Probe response.
STA can determine to join an Extended Multicast service supported AP or not.
AP gets the STA’s subscribed multicast services information (Group Info List) from the AS once the STA authenticates successfully.
AP can update STA’s Group Info List from the AS because the STA may subscribe some new multicast services after it associates with the SSPN.
AP may generate GTK for each group and send to the STA when the STA adds into the group.
The AP will do the IGMP snoop to know whether there is a STA adds to a multicast group and decide whether to send the GTK to the STA.
The AP uses the multicast IP address which is included in IGMP report message as an index of the STA's multicast group information to verify the STA’s legality.
AP and STA use the GTK encrypt and decrypt the multicast frames.
AP may update the GTK when a STA leave the group by the unicasting form, or do the periodical update according to the configuration.
Amy Zhang et al

12. Subscribed Multicast Services Info Getting
November 2006
Subscribed Multicast Services Info Getting
Supplicant
Authenticator AS
Accept/EAP Success/
Key Material/
Group Info List
802.1X EAP Success
EAP Authentication Protocol
Exchange
802.1X EAP Request
802.1X EAP Response
Access Request (EAP Request)
IEEE 802.1X EAP authentication
Group Info List: Record the STA’s subscribed multicast service information. E.g. multicast IP addresses.
Besides sending the PMK, the AS will send the Group Info list over the secure channel when the x authentication successes.
The AP will use the Group Info List to verify the STA is a legal group member and determine to send the GTK of such group to the STA.
Amy Zhang et al

13. November 2006
GTK sending
AP uses IGMP snoop trigger the GTK sending procedure
Once the AP monitor that the STA adds to a multicast group by IGMP snoop, it picks up the multicast IP address in IGMP report message.
AP index the STA’s Group Info List by the multicast IP address to verify whether the STA is a legal group member.
AP sends the GTK and GroupID to the STA after matching successes.
AP and STA may use the GTK encrypt/decrypt the multicast data.
Amy Zhang et al

14. November 2006
GTK sending (Cont.)
The AP use EAPOL-Key frame deliver the GTK to the STA.
STA may maintain more than one GTKs because it may add into more than one multicast group.
Adding a new GroupID information element in EAPOL-Key to identify the GTK of each group.
GroupID may be the multicast MAC address.
AP and STA can use the GroupID index the GTK when they encrypt/decrypt the multicast frame
GroupID
6 octets
Amy Zhang et al

15. Group Info List Update November 2006
STA may subscribe a new multicast service after it associates with the SSPN through the AP, so AP needs to update the STA’s Group Info List from AS when there is no such group information (e.g. multicast IP address) in the STA’s Group Info List
After updating, AP will check again and then determine whether send MTK to the STA for encryption/decryption.
Amy Zhang et al

16. Month Year
November 2006
November 2006
GTK Management
On the AP, each multicast service group may have different GTKs.
The GMK is still used to derive GTKs and the multicast MAC address (GID[i]) is also used to derive the GTKs
GTK ← PRF-X(GMK, “Group key expansion” || AA || GNonce)
GTK[i] ← PRF-X(GMK, GID[i], “Group key expansion”||AA||GNonce );
The multicast MAC address is used to index the GTK
AP/STA uses the multicast MAC address in MAC header to find the correct GTK to encrypt/decrypt.
Group nonce (GNonce) shall be a random or pseudo-random value contributed by the IEEE 802.1X Authenticator.
The GTK shall be derived from the GMK by
GTK ← PRF-X(GMK, “Group key expansion” || AA || GNonce)
TKIP uses X = 256, CCMP uses X = 128 and WEP use X = 40 or X = 104.
AA is represented as an IEEE 802 address and GNonce as a bit string as defined in
The temporal key (TK) shall be bit 0–39, bits 0–103, bits 0–127, or bits 0–255 of the GTK:
TK ← L(GTK, 0, 40) or
TK ← L(GTK, 0, 104) or
TK ← L(GTK, 0, 128) or
TK ← L(GTK, 0, 256)
The EAPOL-Key state machines (see and 8.5.7) configure the temporal key into IEEE via the MLME-SETKEYS.
request primitive, and IEEE uses this key. Its interpretation is cipher-suite-specific
Amy Zhang et al
Amy Zhang et al

17. Roaming Consideration
November 2006
Roaming Consideration
The GTKs will be reassigned by the new associated AP when handover which may not conflict with the exist 11r roaming mechanism.
It could be further discussed if roaming problem is concerned in TGu.
Amy Zhang et al

18. Month Year
November 2006
November 2006
Benefits of Proposal
Introduce a multicast segregation mechanism not only according to the multicast address but also cryptographic separation.
Each multicast services may have its own GTK which can prevent an un-subscription STA use the multicast service for free.
Provide a L2 wired-like multicast deployment mechanism.
GTKs-based multicast segregation is just like the ports-based segregation in wired LAN.
Minimize the threat of insider attack such as the forged multicast frames attack from the BSS domain.
Because the forged multicast frame has no correct GTKs, it can be easily found in L2 by decryption error.
No longer needs to be processed in the upper layer.
Amy Zhang et al
Amy Zhang et al

19. Agenda Why Multicast Multicast Proposal General requirement analysis
Month Year
November 2006
November 2006
Agenda
Why Multicast
Multicast Proposal
General requirement analysis
Amy Zhang et al
Amy Zhang et al

20. Month Year
November 2006
November 2006
G1 Analysis
All proposals (whichever requirements they address) shall describe how they minimize battery consumption for mobile devices.
This proposal has negligible effect on battery consumption.
Amy Zhang et al
Amy Zhang et al

21. Month Year
November 2006
November 2006
G2 Analysis
All proposals (whichever requirements they address) shall describe the security impact of the functions they propose.
This proposal improves security of overall solution.
The AP can make sure that the un-subscription users can not receive the multicast traffic.
Minimize the insider attack by explicitly allowing cryptographic separation of the multicast traffics
Amy Zhang et al
Amy Zhang et al

22. Month Year
November 2006
November 2006
G3 Analysis
All proposals must allow APs to serve legacy STAs in addition to STAs that have been upgraded to 11u. Proposals must describe how this is achieved.
Legacy STAs will have de-crypt errors on multicast frames because they have no MTK
STAs and APs should exchange the multicast capability in Beacon /Association frame. AP will choose the proper policy to transfer the multicast frames. E.g.
Use the GTK encrypt the multicast frame and multicast to the STAs.
Unicast the multicast frame to legacy STAs when the legacy STAs are not too many.
Amy Zhang et al
Amy Zhang et al

23. November 2006
Feedback?
Amy Zhang et al