1. 21-07-0387-00-00011 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0387-00-0001 Title: Problem Statement for Authentication Signaling Optimization Date Submitted: November, 13, 2007 Presented at IEEE 802.21 session #23 in Atlanta Authors or Source(s): Maryna Komarova (ENST) Abstract: This contribution provides analysis of applicability of pre-authentication to different use-cases of roaming agreements presence between the serving, target and home networks.

2. 21-07-0387-00-00012 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 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 stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6 http://standards.ieee.org/board/pat/faq.pdf

3. 21-07-0387-00-00013 Outline Use cases: handover between two networks of the same media type deployed in different administrative domains; Applicability of EAP pre-authentication; Direct pre-authentication; Indirect pre-authentication; Possible solutions; MIIS selection.

4. 21-07-0387-00-00014 Use case 3.1 A mobile device transitions between two networks of the same media type deployed in different administrative domains. There are roaming agreements between the serving and the target network. The target authenticator and authentication server trust information forwarded or signed by an entity belonging to the serving network Requirements: Accordingly to these roaming agreements trust relations should be established between the Serving Authenticator (SA) and the Target Authenticator (TA). Protocols for communication between entities of the MN’s home network and entities of the target network are needed to be defined.

5. 21-07-0387-00-00015 Use case 3.2 A mobile device transitions between two networks of the same media type deployed in different administrative domains. There are no roaming agreements between the serving and the target network There are roaming agreements between one of the MN’s home networks and the target network. This situation is possible when the MN has subscriptions in multiples networks Requirements A way in that information about the target network is provided to the MN should be defined.

6. 21-07-0387-00-00016 Applicability of EAP pre-authentication To optimize the security signaling for the inter-domain handover EAP pre-authentication was proposed [1], [2]. Two modes of EAP pre-authentication are defined: direct pre- authentication and indirect pre-authentication. Requirements: The TA must support pre-authentication; The ability of TA to support pre-authentication must be communicated to the MN; Avoid multiple pre-authentications with the same TA; Avoid pre-authentication for a MN that has non-expired authentication session lifetime; Potential solution: AAA server defines maximum number of pre-authentication sessions per MN; AAA server communicates the authentication session lifetime via pre- authentication signaling protocol; –Such a protocol is not defined yet.

7. 21-07-0387-00-00017 Direct pre-authentication The TA accepts direct pre-authentication. The SA is not involved in the pre-authentication signaling. The pre-authentication is performed either at L2 or at L3 depending on which layer the TA is deployed. If the pre-authentication protocol is defined for a target network technology, the MN requires support from 802.21 in terms of providing information about the TA address and supported pre-authentication mode. Vulnerability to DoS attacks: An attacker it can send numerous pre-authentication requests to the same TA This can be mitigated; An attacker can observe pre-authentication requests arriving in clear and after that it can impersonate a valid user by sending pre-authentication requests on behalf of him. As the attacker is not aware of MN’s credentials, the pre-authentication will fail and the state of the valid MN will change to “unauthorized”. When the valid MN will try to perform a fast authentication using the MSK generated as a result of the pre-authentication, it will not have a correspondent authorization and it will execute the full authentication exchange with the TA. To eliminate the possibility of described attacks, the indirect authentication proposed in [3] may be implemented.

8. 21-07-0387-00-00018 Indirect pre-authentication The TA may process pre-authentication requests only from authorized nodes. In case of presence of roaming agreements between the serving and the target networks the serving authenticator can forward pre-authentication requests from the MN to one or many candidate authenticators. Requirements: The infrastructure knowledge sharing and trust relations establishment are needed between authenticators belonging to different administrative domains.

9. 21-07-0387-00-00019 Indirect pre-authentication: Issues The SA may be implemented at L2 and the target authenticator – at L3 or vise versa. The pre-authentication problem statement draft [3] specifies that the indirect pre-authentication signaling is performed over L3. The L2 authenticator generally is not authorized to communicate with entities in other subnet or administrative domain. Adding functionality to the L2 authenticator leads to increasing the cost of authenticator deployment. Requirement: define proxy agent functionality. If MN performs indirect pre-authentication via the serving authenticator, the latter must distinguish the pre-authentication requests to be processed from pre-authentication requests to be forwarded to the target authenticator. The functionality of SA for indirect authentication is not defined for all access technologies.

10. 21-07-0387-00-000110 Roaming agreements use cases Roaming agreements specify what network entities may communicate with each other. Use case 3.1: roaming agreements are established between the serving and the target networks and either direct (if supported by the TA) or indirect (if supported by both TA and SA) pre- authentication can be performed. Use case 3.2: roaming agreements are established between the target and the MN’s home networks. The pre-authentication is possible in direct mode, if this mode is supported by the TA.

11. 21-07-0387-00-000111 Roaming agreements use cases: Issues Indirect authentication that involves the SA is not possible in use case 3.2 even if the TA supports this pre-authentication mode. Possible solution. The AAA protocols (RADIUS and Diameter) can operate in a proxy mode forwarding authentication messages from the MN to the destination AAA server. The MN can perform the pre-authentication via its home network. If such candidate networks were chosen, indirect authentication can be accomplished by splitting pre-authentication signaling to MN – HA and HA – TA signaling. HA defines a dedicated authenticator in the MN’s home network. The effectiveness and performance of this approach is needed to be analyzed. Requirements. Information provided by the MIIS must contain not only the address of the TA but also the address of the entity that is able to forward pre-authentication packets to the TA. For example, the address of the HA or the authenticator located in the third-party network.

12. 21-07-0387-00-000112 Roaming agreements use cases: Issues (2) In several scenarios pre-authentication with the target authenticator is not possible. This may happen when: The TA does not support direct pre-authentication for security reasons and the SA does not support forwarding of pre-authentication messages from the MN to the TA. The TA does not support pre-authentication. Pre-authentication type supported by an authenticator Possibility of pre- authentication TASAHA* DirectAll modes Yes IndirectDirect No Indirect DirectYes IndirectDirectIndirectYes Indirect Yes *HA may either the home or a third party proxy authenticator. “Indirect” means that some intermediate authenticator is involved in the pre-authentication signalling.

13. 21-07-0387-00-000113 Possible solutions: Pre-authentication with AAA server The pre-authentication result may be cached on the AAA server and it may be pushed to an authenticator belonging to the same AAA domain. IETF HOKEY ERP and pre-authentication can be combined in this case. It is necessary to investigate the performance and deployment cost of this combination. Requirements: AVPs to inform the MN about unexpired session shall be defined [5]. The threshold value for the remaining session lifetime should be estimated. The service provider network may be interested to make only one (or a limited set of authenticators) authenticator publicly accessible for security reasons. Issues: Pre-authentication latency with the target AAA server: If the AAA server is not located in the access network (Remote AAA server) the RTT between the TA and AS is longer. Real data should be examined.

14. 21-07-0387-00-000114 Call flow for authentication with AAA server

15. 21-07-0387-00-000115 Call flow for the pre-authentication with the CAS

16. 21-07-0387-00-000116 Using a dedicated authenticator for pre- authentication For security reasons an administrative domain may define pre-authentication support only for a small subset of authenticators (one at least). This dedicated TA serves to assure pre-authentication between the MN and the AS. When the MN handovers to the TA belonging to the same AAA domain the MSK generated as a result of pre-authentication is pushed to the TA, state of the MN changes to “authenticated” and MN and TA negotiate session keys. Requirements: The entity performing the functionality of an authenticator shall be defined The transport between the MN and this authenticator shall be defined. It is desirable to provide pushing of MSK to the TA before the MN handovers to the TA (proactive mode). The mechanism for mapping between addresses of dedicated TA and TA should be defined. The authenticator that forwards pre-authentication requests must be either trusted for the target AS or it must be able to communicate with the AS that can proxy requests to the target AS.

17. 21-07-0387-00-000117 Call flow for the pre-authentication with using dedicated TA

18. 21-07-0387-00-000118 Choosing the MIIS Issue: The current 802.21 draft does not specify the location of the MIIS. Such a way, the IS may be located in the serving, candidate or home network or even it can be managed by the third party authority. To choose the set of candidate networks the MN must use only trusted and verified information. Authorities providing IS may compete. The MN may receive contradictory or conflicting information. That is why it is desirable to define some trust rating for IS. This trust rating may be based on the previous experience: it is positive when the provided information was correct and it is negative if provided information was not correct. For handover decision making the MN chooses the set of IS with the highest rating. Is the evaluation of trust to the IS is in the scope of the SG?

19. 21-07-0387-00-000119 References I-D: draft-ietf-hokey-preauth-ps-01.txt 21-07-0122-04-0000-Security_proposal.ppt, “Security Optimization During Handovers: 802.21 SG Proposal”. I-D: draft-ietf-hokey-preauth-ps-01 “Technical Requirements document for MIH Security”, http://www.ieee802.org/21/doctree/Security_SG/21-07-0302- 02-0000- MIH_Security_Technical_Requirements_Skeleton.doc. I-D: draft-aboba-radext-wlan-00.txt

20. 21-07-0387-00-000120 Q&A Thank you!