1. Liaison Issues Date: 2006-01-16 Authors: January 2006 January 2006
doc.: IEEE /0065r0
January 2006
Liaison Issues
Date:
Authors:
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
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

2. Summary of TGu Incoming Liaisons and associated issues to address
January 2006
doc.: IEEE /0065r0
January 2006
Abstract
Summary of TGu Incoming Liaisons and associated issues to address
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

3. January 2006
doc.: IEEE /0065r0
January 2006
3GPP2 (TSG-X-S)
R3N5: “Support system selection compatible with existing related standard cellular network techniques”.
The informative section may contain some of the references to 3GPP2 specifications outlined above for the aspects pertaining to cdma2000 interworking. The Requirement Class should be “Required”.
You may want to add requirements similar to what is proposed as R3N5 above in some other Clusters you identified. As a minimum, we suggest the following:
􀂾 SSPN Interface Cluster
􀂾 User Plane Cluster
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

4. January 2006
doc.: IEEE /0065r0
January 2006
3GPP2
R3U3 : Regarding this requirement pertaining to QoS, this is an example of a need to coordinate QoS parameter types and profiles between IEEE and 3GPP2.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

5. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA3)
R3E1 : There is no online enrolment in 3GPP. The User Equipment is assumed to have access to a SIM or USIM, embedded in a smart card.
R3N2 : Only SIM or USIM may be used as credentials in 3G-WLAN interworking. Which of them is selected is specified in TS , section 6.1 and Annex F.
R3P1 : TS states in section 5.2 and 5.3 that "Confidentiality and integrity protection in the WLAN AN link layer is required." Consequently, a STA must not establish a connection with security disabled.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

6. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA3)
R3P2 : 3GPP requires the MAC address to be presented to the AAA server - TS has: “The 3GPP AAA server receives the EAP Response/Identity packet that contains the subscriber identity. The identifier of the WLAN radio network, VPLMN Identity and the MAC address of the WLAN-UE shall also be received by the 3GPP AAA server in the same message”
However, also see additional text in liaison.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

7. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA3)
R3P3 : In 3GPP I-WLAN temporary identities may be used for EAP-SIM and EAP-AKA to protect against passive, but not active, attacks.
TS has: “Temporary Identities (Pseudonyms or re-authentication identities) are generated as some form of encrypted IMSI. Advanced Encryption Standard (AES) (see ref. [17]) in Electronic Codebook (ECB) mode of operation with 128-bit keys is used for this purpose ( see section 6.4 of TS33.234”
However, also see additional text in liaison.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

8. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA3)
R3P4 : This seems to be addressed by R3P1, the EAP methods selected by 3GPP, as they provide mutual authentication, and the STA behaviour defined by 3GPP not to accept communication with link layer security disabled.
R3P5 : It is not clear to us why this mechanism would have to be secured. Who would gain in which way from a compromise of this mechanism? Certainly, in the 3GPP case, after a successful EAP exchange involving the 3G AAA server the AN has shown that it provides access to the home network, i.e. the SSPN.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

9. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA3)
R3A1 : There is a threat in simultaneous access to the same home provider, as explained in SA3’s reply to R3P2 above. But if a user had other subscriptions with different home providers, SA3 would see no threat when the user gained simultaneous access to his multiple home providers simultaneously.
R3M3 : If IEEE u feel that the security of 3G-WLAN interworking may be impacted in any way by a proposal, 3GPP SA3 would be happy to review such proposal.
R3M4 : 3GPP SA3 would be happy to review the security impact of such functionality on 3G-WLAN interworking, if any.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

10. GSMA (IREG) R3E4 – This optional requirement could be useful.
January 2006
doc.: IEEE /0065r0
January 2006
GSMA (IREG)
R3E4 – This optional requirement could be useful.
It is not clear to us how u planned to manage and distribute real-time charging information, especially in cases when one AP is shared between several operators.
The other concern is whether this requirement would cause/require APs to communicate with the Home Network AAA backend server before the STA has actually authenticated to the network?
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

11. GSMA (IREG) R3E4 – This optional requirement could be useful.
January 2006
doc.: IEEE /0065r0
January 2006
GSMA (IREG)
R3E4 – This optional requirement could be useful.
It is not clear to us how u planned to manage and distribute real-time charging information, especially in cases when one AP is shared between several operators.
The other concern is whether this requirement would cause/require APs to communicate with the Home Network AAA backend server before the STA has actually authenticated to the network?
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

12. GSMA (IREG) R3N1 – This requirement is an essential requirement.
January 2006
doc.: IEEE /0065r0
January 2006
GSMA (IREG)
R3N1 – This requirement is an essential requirement.
Our concerns relate to the implications of mechanisms planned to implement this requirement. Would these mechanisms cause/require APs to attempt to communicate with various Home Network backend servers before the STA joins to the BSS? And if so, what are the planned mechanisms to implement the communication?
For our clarification we would like to know how the new functionality for this requirement is planned to be implemented between the STA and the AP. Will a new negotiation protocol be required?
Would it be possible to list at least one credential supplier in beacons and when needed indicate somehow that the AN in question allows access to more SSPNs that listed in the beacon?
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

13. GSMA (IREG) R3N4 – This requirement is an essential requirement.
January 2006
doc.: IEEE /0065r0
January 2006
GSMA (IREG)
R3N4 – This requirement is an essential requirement.
Our concerns relate to the implications of mechanisms planned to implement this requirement. Would these mechanisms cause/require APs to attempt to communicate with various Home Network backend servers before the STA joins to the BSS? And if so, what are the planned mechanisms to implement the communication?
For our clarification we would like to know how the interworking service discovery between the STA and the AP is planned to be implemented. Will a new negotiation protocol be required?
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

14. GSMA (IREG) R3N5 – This optional requirement could be useful.
January 2006
doc.: IEEE /0065r0
January 2006
GSMA (IREG)
R3N5 – This optional requirement could be useful.
We see that distribution of real-time charging information especially in international roaming cases is indeed not practical.
If such mechanism would be implemented, our concerns relate to the implications of mechanisms planned to implement this requirement. Would these mechanisms cause/require APs to attempt to communicate with various Home Network backend servers before the STA joins to the BSS?
R3M2 – This optional requirement would be useful.
Our question for clarification is whether IEEE has indicated they will implement this requirement?
Furthermore, as will involve communication between the STA and the AP, and require new MIH framework, wouldn’t u defined simpler approach be easier and faster to roll out?
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

15. GSMA (IREG) - conclusion
January 2006
doc.: IEEE /0065r0
January 2006
GSMA (IREG) - conclusion
Possible increase or introduction of new communication between the APs and the Home Network backend servers (such as RADIUS) before the STA has authenticated or even joined the BSS. This could be undesired behaviour especially in international WLAN roaming situations.
The second concern relates to the management of the new and dynamically changing advertised information (such as charging information) when APs are shared among multiple operators. How this is planned to be implemented?
The third concern is about the upgrade path of the existing APs. Is it foreseen that a hardware upgrade is required for the existing 802.1X capable a/b/g APs in order to support u defined requirements?
The last concern relates again to communication capabilities between the AP and the Home Network backend server. Are current widely deployed AAA protocols (such as RADIUS) capable of supporting u defined requirements? Will there be an immediate need to extend existing protocols, or even introduce a new protocol?
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

16. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA2)
R3N1 : It would be desirable for 3GPP SA2 to have a mechanism to transport information about available 3GPP PLMNs (SSPNs) to the WLAN UE before attachment of the WLAN UE to the WLAN AP.
R3N3 : Current 3GPP SA2 specifications support such scenarios.
R3N4 : 3GPP interworking services are e.g. support for 3GPP access authentication/authorization, Access to 3GPP IP services.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

17. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA2)
R3S1 : Current 3GPP SA2 specifications provide authorization information to the WLAN AN using standard AAA protocols RADIUS/DIAMETER,, which should be enforced within the WLAN Access Network accordingly.
R3S3 : Current 3GPP SA2 specifications have a mechanism for updating of authorization information to the WLAN Access Network using standard AAA protocols RADIUS/DIAMETER.
R3U1 : Current 3GPP SA2 specifications support such scenarios.
R3U3 : 3GPP SA2 is working on specifying interworking with QoS enabled WLAN Access Networks for Rel-7.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

18. January 2006
doc.: IEEE /0065r0
January 2006
3GPP (SA2)
R3A1 : 3GPP SA2 sees a potential security threat when enabling a device to simultaneously connect to networks under the control of different, unrelated service providers. 3GPP also has a concept of a Home Network for a user and the user is not considered to have multiple home networks.
R3S4 : In 3GPP, accounting related information is collected at layer 3 and above.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

19. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
Comments from Bernard Aboba (& Mike Moreton) r0
R8E1 – In large scale roaming deployments, an AP will typically not have knowledge of all the potential roaming realms which customers may be able to authenticate to. For example, an AP typically is not configured with a realm routing table, but just a "default route" to the local AAA proxy or server. The local AAA proxy in turn may also be configured with a "default route".
As a result, the AP may not know what realms are available, nor may it have information on the services (such as enrolment) provided by those realms. The AP may not be able to inform the STA whether online enrolment is supported by a realm, or even if a realm is reachable by the STA.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

20. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8E2 – During the recent EMU BOF, there was discussion of enrolment support within EAP. Rohan Mahy has submitted a draft on this subject:
This would support the document's assertion that "a solution may be outside the scope of this task group".
However the current EMU WG Charter does not include a work item on enrolment.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

21. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8E4 – The charges associated with access to a realm may vary not only with the realm but also with the path by which the realm is accessed -- the "decorated NAI". Since charges may also vary by time of day or day of the week, the information required to fully inform the STA may be quite complex.
For the reasons described in R8E1, an AP may not know the realms accessible from within a given "Virtual AP", or the charges associated with access to that realm via any path, at any time.
Since neither EAP nor AAA provides a mechanism for communication of charges, it is not clear how this requirement can be satisfied other than by manual configuration of an AP.
We concur with the document characterization of this requirement as "optional".
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

22. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8N1 –As described in the analysis of R8E1, where a single physical/virtual AP provides access to an undetermined number of realms an AP may not know what realms are accessible from a given "virtual AP". As a result, the AP may not have the information available to satisfy this requirement.
[Mike Moreton] My assumption is that this information would either be hard configured into the AP (not desirable) or that the query would be passed on to some other device using some protocol designed by another standards organisation (much more desirable).
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

23. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8N2 –For a STA to select the correct credentials, it needs to be aware of the realms available to it, as well as the EAP method to be used with the desired realm. Once a STA has enrolled in a realm, it presumably is configured with the EAP method to be used for that realm, so that the problem comes down to determining which realms are available.
Therefore the issues inherent in realm discovery (see R8E1) are applicable to this requirement as well.
[Mike Moreton] I've never quiet understood this requirement, but my assumption is that the response to a "Do you provide connection to this NAI?" question would also include an optional field that could be used to indicate the realm within the network indicated by that NAI. How that information gets to the AP is again out of our scope.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

24. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8N3 – That document indicates that "Its not acceptable to require a separate "virtual" AP for each SSPN", but does not provide more detail on how this statement was arrived at. Certainly, existing "Virtual AP" mechanisms do not scale much beyond a dozen "Virtual APs" per physical AP. However, recent submissions within IEEE appear to be aimed at removing those limitations, by enabling multiple "Virtual APs" to be supported within a single Beacon/Probe Response, as well as by enabling support of "hidden virtual APs" that are not advertised.
It would therefore appear that in the long term it may be possible to remove many of the "virtual AP" scaling limitations.
It is suggested that IEEE u re-examine whether R8N3 is really required.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

25. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8N7 - Unbroadcasted or "hidden" SSIDs are one mechanism by which the scalability of advertisement mechanisms may be improved. In a large scale roaming deployment, presumably many of the SSIDs would be "hidden", since even support for multiple "virtual AP" advertisements per Beacon might not be sufficient.
Since a "hidden" SSID is by definition not advertised, a Probe Request/Response exchange is typically necessary to determine whether it is supported. If a STA has multiple SSIDs in its preference list which could conceivably be "hidden" then it is not clear how it can determine whether they are present without probing for them.
We concur with the document characterization of this requirement as "not required".
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

26. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8P2 – RFC 4017 requires EAP methods supporting "mutual authentication" and "key derivation" so that a STA supporting IEEE i can determine whether an AP to which it has associated has been authorized by the AAA server.
RFC 4017 also includes "Channel Binding" as an optional security claim. Among other things, support for channel bindings enables a STA to check with the AAA server whether an AP is impersonating another AP to the STA.
More recently, IEEE 802.1ar "Secure Identity" has been chartered in order to enable verification of ownership of MAC addresses.
Therefore there appears to be work in progress relevant to this requirement.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

27. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8A1 – Simultaneous access to multiple wireless networks has been demonstrated using existing standards:
As a result, new functionality may not be required to satisfy this requirement, if a scalable "Virtual AP" model is available.
[Mike Moreton] And if we come up with a proper solution to the MAC address anonymity problem it may be impossible to prevent the STAs doing this. Note that some operators have a big issue with this requirement.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

28. January 2006
doc.: IEEE /0065r0
January 2006
IETF EAP (unofficial)
R8I1 - Multiple IEEE 802 groups have already become involved in the specification of Emergency Service capability -- IEEE k, v, 802.1AB (via TIA LLDP MED), raising questions about the overall coherence of the effort, let alone compatibility with the work of IETF WGs such as ECRIT and GEOPRIV.
IEEE u may therefore wish to consider whether addition of another group will help or hinder the effort to develop a coherent Emergency Services architecture.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor

29. 3GPP2 TGS-S, TGS-X Suggest new requirement: R3U3 :
January 2006
doc.: IEEE /0065r0
January 2006
3GPP2 TGS-S, TGS-X
Suggest new requirement:
R3N5: “Support system selection compatible with existing related standard cellular network techniques”.
R3U3 :
pertaining to QoS, this is an example of a need to coordinate QoS parameter types and profiles between IEEE and 3GPP2.
Stephen McCann, Siemens Roke Manor
Stephen McCann, Siemens Roke Manor