INTERNET-DRAFT Miyoung Kim Expires July 2005 Youngsong Mun Soongsil University Jaehoon Nah Seungwon Sohn ETRI January 2005 An Authentication Scheme using AAAA in Hierarchical MIPv6 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This internet draft will expire on July 5, 2005. Abstract To reduce the amount of the signaling messages occurred in movement, Hierarchical Mobile IPv6 (HMIPv6) has been introduced as the hierarchical mobility management architecture for MIPv6 by regarding the micro movement. Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 1] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 When approaching the visited link, the authentication procedure should be done successfully prior to any mobility support message exchanges. The Authentication, Authorization and Account(AAA) authentication service is applied gradually to the wireless LAN and Cellular networks. However, it may bring about the service latency for the sessions of needing the real-time processing due to not providing the optimized signaling in local and frequent movements. In this draft, we propose the authentication architecture with delegation scheme to reduce the amount of signaling message and latency to resume for local movements by integrating it with HMIPv6 architecture. 1. Introduction The popularization of the broadband hotspot service using wireless LAN technology and the increase of the needs for security infrastructure to authenticate an user with secure manner in cellular network result in the Diameter-based AAA service being applied to various kinds of related technologies. Moving into the visited network from the outside, visited network and mobile node should take a mutual authentication to prevent them from being vulnerable. It should be performed in prior to any mobility exchanges between the AAA servers in visited and home domain that is not adequate for HMIPv6 hierarchy and its design rationale in in-bound roaming which brings about the considerable service latency. In his draft, we propose the optimization of mobility signaling and autentication messages by adding the authentication scheme to the same hierarchy of HMIPv6 when inbound roaming occurs. To detail our idea, we introduce the í«Delegationí¯and the AAA delegation entity is able to authenticate the node and distributes the keying-materials in behalf of MNí¯s Home Agent[6]. Moving the new MAP domain, MN receives the RA message containing the MAP information from the Access Router and determines which MAP is used for MN from the MAP list. If an intruder multicasts the forged RA, MN obtains the compromised MAP information that results in the packet redirection attack. To protect against this threat, SEND WG recommends using the IPsec and CGA in router discovery, however manual keying applied to IPsec is not adequate for the case of large amount of MN exists. Therefore, an infrastructure enabling the dynamic SA management should be provided If the address of new MAP is different with previous MAP where the MN moves to a new MAP domain, LCoA and RCoA should be configured for registration to the MAP and HA. MN obtains the LCoA on the current link with stateless manner where RCoA from the MAP information, prefix and some flags in RA advertised from access router. At this time, an attacker can forge the RA message and MN obtains Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 2] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 miss-configured. LCoA and RCoA that results in DoS and packet redirection. Preventing the vulnerability of the above case requires the security service first. When the MN moves to another subnet within the MAP domain(in-bound roaming), it should register LCoA to the MAP in the current domain without Home Registration. However, since no pre-configured SA between MN and MAP exists, the message exchanges are liable to be intercepted by an attacker as described in[2]. Because the binding update message contains the LCoA, the packets sent from the CN is apt to be tunneled to an illegal node if the LCoA is cooked by an attacker. In case of waiting the binding acknowledge after attacker which causes the MN get lost the on-going sessions. Therefore, the MN and MAP should authenticate the sender of binding update and acknowledge message[8]. 2. Model and Entities The following figure shows the model used in communication to distribute the session key between mobile node and attendant thorugh the AAA(Diameter[2]) infra structure. +------+ +------+ | HA | | CN | +------+ +------+ ^ ^ | | | | | | v v +----------+ +----------+ | AAAh | "AAA Network" | AAAv | | Server |<----------------->| Server | +----------+ +----------+ ^ ^ | | | | | | v v +---------------------------------+ | MAP + AAAv | +---------------------------------+ ^ ^ | | | | | | v v Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 3] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 +----------+ +----------+ | AAA | | AAA | |Attendant | | Attendant| +----------+ +----------+ ^ . . . v +----------+ <----> : Secure Channel | Mobile | <....> : Insecure Channel | Node | +----------+ Figure 1. AAA Authentication Model The AAA network provides AAA servers with the secure communication channels. The V_AAA and Attendant are the entities in the same administrative domain so they share information on how to authenti- cate each other. The SAs based on pre-assigned authentication method exist between H_AAA and MN's home agent.[4] However, when the mobile node with its NAI which belongs to the domain of H_AAA is entering into the foreign link in another domain, the attendant is unable to authenticate the mobile node since there's no security associations and information to generate the shared security key between them. To perform the normal Biding Registration Procedure[4], the authenti- cation should be done prior to any mobility supporting procedures. The creation and distribution of the session key can be performed by H_AAA or Home Agent [1]. The Diameter protocol[2] is used to encapsulate the authentication request messages from the MN and deliver it to the AAA entity in the destination domain which is able to identify the MN. 2.1 Terminologies Attendant: AAA entity which is the local AAA system entry point and the local address provider/registry. In 802.11 wireless network [5]. AP can play a role for this. Term from [3]. AAA client: Attendant. It acts as a proxy to process the authenti- cation request/reply from(to) mobile node. In the perspecive of AAA infra-structure, the attendant can be a client sending a authentication request in behalf of mobile node. AAA server in home domain(H_AAA): AAA server of home network. The home agent and mobile node have the same domain identifier with its AAA server. It is assumed that the contract for global roaming across the different domains is established between AAA servers. AAA server in visited domain(V_AAA): AAA server of visited network Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 4] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 AVP(Attribute Value Pair): The payload data to send the authenti- cation request/answer within the AAA messages to the entity associated with SA. Binding: home address/care-of address association for a mobile node on a mobility aware IPv6 node. MN(Mobile Node): an IPv6 mobile node distigushed with its NAI or home address. CN(Correspandent Node): an IPv6 fixed or mobile node communicating with the MN. It maintains the active session with the MN. NAI(Network Authentication Identifier): An identifier to represent where the entity belongs. The entities in a domain also have the same domain identifier in its NAI. The way to represent it is described in [6]. CoA(Care-of Address): Temporary address used by MN during in the visited link. SA(Security Association): The security materials and algorithms to calculate the secure shared key between peers. HA(Home Agent): Home agent of MN which has the same doamin identifer with its AAA server. HoA(Home Address): A fixed address of MN allocated in its home link. The home address belongs to the home network and is in general well known by the mobile node even if the protocol described here supports home address allocation. Delegation Option: An option to delegate the role of generating and distributing the session key used between attendant and mobile node to an AAA server in the visited domain. Delegation Entry List: The instances of the table which indicate the MN's home agent or AAA server has delegated the key management roles to the AAA server in the visited domain. Only when the H_AAA/Home Agent and V_AAA have the same SA context, the the delegation entry is created as a response to Authentication Request. This entry has information on which MN is managed by V_AAA and how long it is vaild(lifetime), etc. Security Context: A set of information on how to process the authentication securely. It contains the algorithms to be used in creation of the session key and the security-related functions (e.g. hash, random generator, etc). Thus it represents the capabilities of the AAA/mobility Nodes. MAP+AAA: A composite entity acting a role of Mobility Anchor Point and AAA server in visited link in behalf of the home AAA server during the delegation lifetime is alive. 3. Message Sequence 3.1 Authentication Procedure Regarding the Locality As considering the local movement, HMIPv6 employs the access router and MAP acting the HA role where local movement is handled within the domain without forwarding the binding update to MN's Home Agent. However, since the security entity in visited link has no idea of how Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 5] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 to authenticate the MN, the authentication message exchanges are sent out of the domain that results in the considerable amount of service latency although the in-bound roaming occurs. Authentication must be done before starting the binding update and binding key should be generated to make BU message secure. Using the IPsec brings about the difficulty of manual keying and the overstrain of the cryptographic processing and increase of round trips due to the IKE message exchanges when making a new SA. The authentication based on AAA infrastructure provides the strong security with its natural service. The messages are in [7,9,10]. 3.2 The Authentication and Binding Registration Procedure for Inter-Domain Movement When the MN moves to the new subnet, it should be authenticated by the security entity of the subnet to make use of the resource in it. If it fails to authenticate, the on-going sessions will be lost. The MN searches the Attendant on the visited link accord-ing to the [7, 10] where it uses EAPoL message to authenticate itself for being allowed to use the link. The MN sends the messages to attendant in which Secure_Param_MN is contained for successful authentication and binding key generation. Secure_Param_MN contains the NAI to recognize the home domain of the MN, Nonce index to prevent replay attack, MN's home address, CoA of the MN configured in visited link, SPI(Security Parameter Index), delegation request flags and authentica-tor to verify the integrity of the message. In case of real-time authentication required, delegation flag may set in the message. Upon receiving the EAPoL messages, the attendant converts it to the DIAMETER message, AReq and sends it the AAA server in visited link. The payload of AReq message contains the DIAMETER AVP and its options encapsulating the security materials received from the MN. NAI, Nonce_Index, SPI and Signature options are grouped to Security AVP and Home Address and CoA options are for Address AVP and the Delegation option is for Ac-tion AVP if it wishes to use the delegation. On receiving the AReq message, MAP+AAA entity copies the Secure_Param_MN into the secure storage and forwards it to the AAA server in MN's home domain to authenticate the MN and forwards it to HA to obtain the binding key where the path between HA and home AAA server is protected by the preconfigured IPsec ESP. On receiving the message, the HA authenticates the MN and copies the Secure_Param_MN in the secure storage and returns its Secure_Param_HA. If the 'delegation' option is set in the received message, it returns the results of processing the request together. If it fails to authenticate it returns an error code and destroys the Secure_Param_MN cached in secure storage temporally. This message contains the Nonce Index, HA's address, SPI, Authenticator and results. Upon receiving the message containing the Secure_Param_HA, the home AAA server converts it to DIAMETER form, ARsp and verifies the availability of delegation if it is set in the message. Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 6] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 If successful, it sends the message to attendant after obtaining the Secure_Param_HA. It checks if the requested delegation is available or not. If successful case of the delegation, MAP+AAA entity plays a role of HA and authenticate the MN on behalf of MN's HA until the lifetime expires. MN AR MAP+AAAv AAAh HA | | | | | | Secu_Param_MN | | | | |-------------> | | | | | (EAPoL) | AReq | | | | |-------------->| | | | | | AReq | | | | |-------------->| | | | | save | | | | | Secu_Param_MN | | | | | | Secu_Param_MN | | | | |---------------->| | | | | | | | | |Authenticate MN + | | | |save secu_parm_MN| | | | | | | | | |<----------------| | | | | Secu_Param_HA | | | | | | | | | |Generate MN's key+ | | | AReq | | | | |<--------------| | | | | save | | | | | Secu_Param_HA | | | | AReq | | | | Secu_Param_HA |<--------------| | | |<--------------| | | | | (EAPoL) | | | | | BU |(BU(LCoA),key) | | | |------------------------------>| | | | | | | | | (BA(RCoA,key) | | | |<------------------------------| | | | | | | | | |(BU(RCoA,key) | | | |---------------------------------------------------------------->| | | | | | | |(BA(RCoA,key) | | | |<----------------------------------------------------------------| | | | | | | | | | | v v v v v Figure 2. The authentication and binding registration procedure for inter-domain movement Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 7] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 3.3 Authentication Procedure using the delegation for Intra-domain Movement In case of in-bound roaming, the authentication procedure takes more simplified fashing if the delegation is activated MN AR MAP+AAAv AAAh HA | | | | | | Secu_Param_MN | | | | |-------------> | | | | | (EAPoL) | AReq | | | | |-------------->| | | | | | | | | | |-------------->| | | | | | | | | | |---------------->| | | | | | | | | |<----------------| | | | | | | | |<--------------| | | | +verify MN | | | | AReq |Generate MN's key | | Secu_Param_HA |<--------------| | | |<--------------| | | | | (EAPoL) | | | | | BU |(BU(LCoA),key) | | | |------------------------------>| | | | | | | | | | +create BCE | | | (BA(RCoA,key) | | | |<------------------------------| | | | | | | | | | | | | v v v v v Figure 3. Proposed authentication procedure using the delegation for intra-domain movement The authentication and binding registration procedures are performed for in-bound roaming. After finding the attendant in visited link the MN sends EAPoL message with same parameter described in 3.2 to request the authentication where the delegation may be set. Attendant delivers the message to MAP+AAA after converting it to DIAMETER form. If delegation option is included in the messages, the previous authentication in addition to the authentication processing results to confirm the status of MN's request for authentication. The MN registers the MAP after generatin the binding key from the Secure_Param_HA. Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 8] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 4. Security Considerations This draft describes the authentication scheme applicable to the HMIPv6 base architecture by integrating the role of authentication with the MAP entity. Doing so requires some security considerations when deploying the real environment. To optimize the message exchange steps and to provides the continuity of the mobility service, we introduces the 'Delegation Model' which enables the MN to establish the session key with its Home Agent and the attendant in the visited link. Once the delegation is activated, the visided AAA server, namely the MAP+AAA, plays a role of authentication for the requesting MN on behalf of the home AAA server until the delegation lifetime expires. The delegation model defined in this document does not create new security breaches for the IPv6 MN and AAA entities in home and visited domain. On the contrary, it allows for an effective and efficient authentication and authorization to the MN when roaming across the subnet links in the same domain as well as between different domains. As the rocality of MN's movement grows, this method is effective to used when the MN is moving rapidly across the links in a same AAA domain. 5. Acknowledgments All the RFC's, ID's, freely available 802.11 standards, and web-sites. 6. References [1] H. Soliman, C. Castelluccia, "Hierarchical Mobile IPv6 mobility management(HMIPv6)", IETF Internet Draft, Mobile IP Working Group, June 2003. [2] L. Kleinrock, Queueing Systems, Volume 1: Theory, John Wiley & Sons, 1975. [3] K. Chiang, N. Shenoy, "A Random Walk Mobility Model for Location Management in Wireless Network", in proc. IEEE PIMRC Conf. Sept. 2001.. [4] S. Pack, Y. Choi, "Performance Analysis of Hierarchical Mobile IPv6 in IP-based Cellular Networks", in proc. IEEE PIMRC Conf. Beijing, Sept. 2003. [5] Waterloo Maple, "Computing the Steady-State Vector of Markov Chain", www.mapleapps.com, 2001. Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 9] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 [6] M. Kim, Y. Mun, J. Nah, S. Sohn, "Localized Key Management for AAA in Mobile IPv6", IETF Internet Draft, Mobile IP Working Group, Oct. 2002. [7] F. Dupont, J. Bournelle, "AAA for Mobile IPv6", Internet Draft, IETF, Nov. 2001. [8] A. Mankin, B. Patil, D. Harkins, E. Nordmark, P. Nikander, P. Roberts, T. Narten, "Threat Model introduced by Mobile IPv6", Internet Draft IETF, May 2001. [9] Pat. R. Calhoun, Erik Guttman, Jari Arkko, "DIAMETER Base Protocol", Internet Draft, IETF, July 2002. [10] F, Le, B. Patile, Charles E. Perkins, "Diameter Mobile IPv6 Application", Internet Draft, IETF, Nov. 2001. 7. Author's Address Miyoung Kim, Ph.D Student Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-812-0689 Fax: +82-2-822-2236 E-mail: mizero31@sunny.soongsil.ac.kr Youngsong Mun, Professor Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-820-0676 Fax: +82-2-822-2236 E-mail: mun@computing.ssu.ac.kr Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 10] INTERNET-DRAFT An Authentication Scheme using AAAA in HMIPv6 Jan. 2005 Jaehoon Nah Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-6749 Fax: +82-42-860-5611 E-mail: jhnah@etri.re.kr Seungwon Sohn Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-5072 Fax: +82-42-860-5611 E-mail: swsohn@etri.re.kr Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Miyoung Kim and Youngsong Mun. Expires July 2005 [Page 11]