1. 21-07-0035-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0035-00-0000 Title: Access Control for IEEE 802.21 IEs Date Submitted: January, 15, 2007 Presented at IEEE 802.21 session 18 in London Authors or Source(s): Eleanor Hepworth, Raffaele Giaffreda, Ian Herwono, Ramon Aguero, Eranga Perera, Kostas Pentikousis, Ralf Jennen, Oliver Blume, Anand Prasad Abstract: This presentation discusses the need for access control for IEEE 802.21 IEs, and proposes some additional text to be included in the base standard.

2. 21-07-0035-00-0000 IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. 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. 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 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html

3. 21-07-0035-00-0000 Motivation Operators would like the ability to control access to IEs provided in response to a query from an MIH User. This allows operators to choose what information they share with whom. For example, more sensitive network performance information may only be shared with MIH users that have a appropriate subscription with that operator. NB “access control” synonym for “access control to Information Elements” unless otherwise stated

4. 21-07-0035-00-0000 MIIS access control – Ambient background from Ambient Networks: framework for managing dynamic network context (enhanced set of information elements in.21 speak) within current set of IEs some are more sensitive than others access control solutions much more compelling if enhancement to the current 802.21 set of IEs is considered the richer is the set of information elements the more opportunities for improving media independent services (compare 21-06-0472-00-0000- Handover_Use_Cases_More_IEs.ppt ) 21-06-0472-00-0000- Handover_Use_Cases_More_IEs.ppt i.e. giving the means to assess current suitability of a candidate network to carry out the required service before handover

5. 21-07-0035-00-0000 What is needed access control policy needs to be applied to queries This can be viewed as an extension to the current controls applied to queries when users are not authenticated with the network (access granted to IS not to CS or ES) We need: Information about the user– this can be used to index policy information An environment in which the information provided by the user is meaningful in some way – can the user be trusted? Policy information that can be combined with attributes of the user to determine what information they can access (out of 802.21 scope)

6. 21-07-0035-00-0000 Policy Based Information Access Control high level proposal (see IETF GEOPRIV) Information Recipient Information Server Information Generator PDP / Policy Repository NEW (out of.21 scope) Existing already in 802.21 UE / MN source of IEs 802.21 perspective: authenticated user request for IEs: (UIDx, IEy)

7. 21-07-0035-00-0000 Solutions suggested In order to implement Access Control the request for IEs to the IS need to be accompanied by some indication of the user_ID for the user requesting it. Two solutions are envisaged

8. 21-07-0035-00-0000 Solution #1 User_IDs can be related to “operator subscription” (i.e. user_ID is what L2 authenticates in order to grant access) – could exploit trusted environment to implement access control UE/MN asks for IEy, MIH of the network node resolves user_ID based on media dependent info (i.e. channel ID, MAC address etc.) requires some changes to MIHF who has now to interact with all L2 technologies so that authenticated user_ID can be passed when IEy is requested it assumes authentication

9. 21-07-0035-00-0000 Solution #2 User_IDs can be unrelated to subscription (Fed_UID?) – in this case a separate authentication needs to be performed for MIIS access control purposes UE/MN asks for IEy passing also user_ID in a media independent way: requires change to the protocol used for accessing IEs. It puts more requirements to MIHF who now has to authenticate user_ID it doesn’t assume L2 authentication

10. 21-07-0035-00-0000 Example scenarios (Soln #1) User_IDs can be related to “operator subscription” (i.e. user_ID is what L2 authenticates in order to grant access) – could exploit trusted environment to implement access control

11. 21-07-0035-00-0000 Information Recipient Information Server Information Generator PDP / Policy Repository UE / MN

12. 21-07-0035-00-0000 MIHF Single admin domain – blue telco AP UID X AAA UID X OK … Mapping MAC X  UID X  Accept IE X UID X, IE X MIIS UID X, IE X assumption on this mapping existing at L2 Policy Engine (PDP) Policy Decision UID X, IE X needed to index policy information IE X =zz radius client

13. 21-07-0035-00-0000 Information Recipient Information Server Information Generator PDP / Policy Repository UE / MN

14. 21-07-0035-00-0000 XACML Policy Example Assertion servers will be contacted to resolve attribute values that are not provided in access request, but required for policy decisions, e.g. user membership profile Here, the user can be granted access to the IE with the condition/obligation that Layer 2 encryption between MN and Serving PoA is in place Serving PoA may need to send a “link command” toward L2 to get the L2 encryption status Request Subject Resource user id domain UIDx blue.telco IE id IEx Policy Target Subj. AD:Level GOLD Res. AD:ie.id IEx = = Rule Obligation Effect = Permit “L2 encryption must be ON” Attribute Finder Assertion Server User id = UIDx: Level = GOLD

15. 21-07-0035-00-0000 Composite scenario blue and purple telco AP IE Y UID X UID Y

16. 21-07-0035-00-0000 MIHF Multi-admin domain blue and purple telco AP UID X AAA UID X OK … Mapping MAC X  UID X  Accept IE Y UID X, IE Y MIIS UID X, IE Y assumption on this mapping existing at L2 IEy is an IE of purple telco that relate to a different user subscription identified by UIDy: UIDx and UIDy need to be related somehow: work in progress… Policy Engine (PDP) UID X, IE Y MIIS Policy Decision UID Y, IE Y IE Y =yy UID X  UID Y radius client

17. 21-07-0035-00-0000 Example scenarios (Soln #2) User_IDs can be unrelated to subscription (Fed_UID?) – in this case a separate authentication needs to be performed for MIIS access control purposes

18. 21-07-0035-00-0000 MIHF Multi-admin domain blue and purple telco AP Fed_UID X IE Y MIIS Fed_UID X, IE Y Policy Engine (PDP) IE Y MIIS Policy Decision Challenge / Response IE Y =yy

19. 21-07-0035-00-0000 Conclusions To provide differential access control on information provided to a user, the identity of the user must be known and trusted. This can be achieved by relating the services to the authentication chain, e.g. services are only provided in the access network or the home network where the relationship between the user and the network is known. (Soln #1) This does not prevent MIH services being hosted elsewhere, but will require an alternative means for establishing trust relationships between user and server. (Soln #2) Amendments to current standard – work in progress

20. 21-07-0035-00-0000 The End