NEMO Working Group T. Kwon Internet-Draft S. Baek Expires: January 12, 2006 S. Pack Y. Choi Seoul National University July 11, 2005 AAA for NEMO draft-kwon-aaa-nemo-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The purpose of this paper is to describe an AAA protocol designed for NEMO services. The proposed AAA protocol retains the NEMO mobility transparency in the NEMO basic support protocol, while providing all the required AAA functionalities for mobile network nodes. In addition, the proposed AAA protocol reduces authentication latency by localizing AAA process. Kwon, et al. Expires January 12, 2006 [Page 1] Internet-Draft AAA for NEMO July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 2.1 General Terms . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Payloads . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The Model and Assumption . . . . . . . . . . . . . . . . . . . 5 4. AAA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 MR Authentication . . . . . . . . . . . . . . . . . . . . 7 4.1.1 Inter-Domain AAA Procedure . . . . . . . . . . . . . . 7 4.1.2 Intra-Domain AAA Procedure . . . . . . . . . . . . . . 9 4.2 VMN Authentication . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 15 Kwon, et al. Expires January 12, 2006 [Page 2] Internet-Draft AAA for NEMO July 2005 1. Introduction According to NEMO terminologies [1], a mobile network (NEMO) is defined as a network whose point of attachment to the Internet varies as it moves about. A NEMO consists of mobile routers (MRs) and mobile network nodes (MNNs). Each NEMO has a home network to which its home address belongs. When a NEMO is in its home network, the NEMO is identified by its home address (HoA). On the other hand, the NEMO configures a care-of-address (CoA) on the egress link when the NEMO is away from the home network. At the same time, on the ingress link, the MNNs of the NEMO configures CoAs, which are derived from the subnet prefix (i.e. NEMO prefix) in the home network. This NEMO prefix remains assigned to the NEMO while it is away from the home network. The assigned NEMO prefix is registered with the home agent (HA) by the NEMO basic support protocol [2]. To make NEMO services feasible in public wireless Internet, well- defined authentication, authorization, and accounting (AAA) protocols should be accompanied. However, to the best of our knowledge, no specific AAA protocols have been proposed for NEMO support. Even if a number of AAA protocols have been proposed for host mobility, all of them are based on per-node AAA operations. Therefore, it cannot directly applied to NEMO environments containing both local fixed nodes (LFNs) and visiting mobile nodes (VMNs). In this document, we propose a novel AAA protocol that provides efficient AAA procedures in NEMO environments. 2. Terms and Abbreviations 2.1 General Terms Attendent : An AAA entity which is the local AAA system entry point. The attendant extracts identification and authorization data sent by the MR or the VMN and forwards them to AAAL in order to request authentication. AAAH : AAA server of the home network. AAAL : AAA server of the foreign network. MR : mobile router. AR : access router. VMN : visiting mobile node. A VMN is temporarily attached to the MR's subnet by obtaining its CoA from the NEMO prefix. LFN : local fixed node. This belongs to the mobile network and is Kwon, et al. Expires January 12, 2006 [Page 3] Internet-Draft AAA for NEMO July 2005 unable to change its point of attachment. MNN : mobile network node. MNNs such as VMN and LFN are nodes in a NEMO. MN : mobile node [4]. 2.2 Payloads LC (local challenge) : a challenge issued by the attendant. This is a random number for authentication procedures. NAI (network access identifier) : identitiy of MR or VMN. MRs and VMNs are identified by their network access identifiers. RPI (replay protection indicator) : Either a timestamp or a random number can be used as an RPI. H@ : Home Address HA@ : Home Agent Address SA (security association) : a relationship between a sender and a receiver that afforcd security services to the traffic carried between peers. key_aaa : an AAA key in the pre-shared SA between an MR and an AAAH CR (Credential) : an AAA credential which is used by the AAAH to authenticate the MR or the VMN. The MR or VMN encrypts the LC using the key in the pre-defined SA with its AAAH. The encrypted value is called as a credential. CR_L (Local Credential) : an AAA credential which is used by the AAAL to authenticate the MR. The MR encrypts the LC using the key_local. The encrypted value is called as a local credential. key_local : a dynamic key in the temporal SA between an MR and an AAAL server key_home : a dynamic key in the temporal SA between and an MR and its HA SP_LOCAL : security parameters to establish an temporal SA between an MR and an AAAL SP_HOME : security parameters to establish an temporal SA between an MR and its HA Kwon, et al. Expires January 12, 2006 [Page 4] Internet-Draft AAA for NEMO July 2005 2.3 Messages In this section, the fields of the new proposed messages are detailed. Attendant Solicit (AS) : An IPv6 router solicitation message with the extended AAA option Attendant Advertisement (AA) : An IPv6 router advertisement message with extended AAA option Athentication Request (AReq) : NAI, RPI, H@, HA@, LC, CR Authentication Reply (ARep) :NAI, RPI, H@, HA@, SP_HOME, SP_LOCAL AA-Mobile-Router-Request (AMR) : NAI, RPI, H@, HA@, LC, CR AA-Mobile-Router-Answer (AMA) : NAI, RPI, H@, HA@, SP_LOCAL, SP_HOME AA-Home-Agent-Request (AHR) : NAI, RPI, H@, SP_HOME AA-Home-Agent-Answer (AHA) : NAI, H@ AA-Mobile-Router-Local-Request (AMLR) : NAI, RPI, H@, HA@, LC, CR_L AA-Mobile-Router-Local-Answer (AMLA) : NAI, RPI, H@, HA@ 3. The Model and Assumption In this section, the AAA architecture for NEMO services is introduced with basic assumptions and concepts such as SA and challenge/response authentication. Kwon, et al. Expires January 12, 2006 [Page 5] Internet-Draft AAA for NEMO July 2005 Foreign Domain Home Domain of MR Home Domain of VMN +--------+ "AAA network" +--------+ "AAA network" +--------+ | AAAL |<------------------->| AAAH |<------------------->| AAAH | | server | | server | | server | +--------+ +--------+ +--------+ ^ ^ ^ | | | | | | v v v +-----------+ +---------+ +---------+ | AAA | | Home | | Home | | Attendant | | Agent | | Agent | +-----------+ +---------+ +---------+ ^ | | v +--------+ | Mobile | | Router | +--------+ ^ | | v +----------+ | Visiting | | Mobile | | Node | +----------+ Figure 1. NEMO AAA Architecture Figure 1 illustrates a reference architecture for AAA in NEMO environments, which is similar to that of Mobile IPv6 [4,5]. The AAA architecture is based on the DIAMETER protocol [3]. The AAA architecture consists of multiple autonomous wireless networks, each of which is called a domain. Each domain has an AAAH server and/or an AAAL server in order to authenticate any node in a DIAMETER-compliant manner. The AAAH server of the MR has the profile of the MR and it shares a long-term key with the MR. Likewise, the AAAH server of the VMN shares a long-term key with the VMN. The AAAL server takes charge of an AAA procedure for a visiting NEMO (VMNs and MRs). We assume that the AAAL server also serves as the home AAA server for an AR by keeping a long-term key. The trust relationship between the AAAH server of the MR and the AAAL server of the visited network is maintained through the DIAMETER protocol. When the NEMO Kwon, et al. Expires January 12, 2006 [Page 6] Internet-Draft AAA for NEMO July 2005 changes its point of attachment, the MR needs to be authenticated and authorized before it accesses the same foreign network (intra-domain handoff) or a new foreign network (inter-domain handoff). To accomplish this, the MR and AR authenticate each other through a mutual authentication procedure that involves both the AAAH server of the MR and the AAAL server of the AR. An attendant (which is the same as the AAA client) is an entity that requests authentication procedures to the AAA system. In Mobile IPv6 networks, ARs normally act as the attendants for an MN [4]. In our protocol, the AR serves as an attendant for the MR's authentication, while the MR serves as an attendant for VMN's authentication. In the latter case, the MR broadcasts attendant advertisement messages and receives authentication request messages from VMNs within the NEMO. Regarding SAs, it is assumed that the MR's AAAH and the VMN's AAAH have a pre-established SA. In addition, it is assumed that the MR and LFNs have already authenticated each other by some mechanism, which is out of the scope of this document. 4. AAA Protocol 4.1 MR Authentication 4.1.1 Inter-Domain AAA Procedure When a NEMO enters a new foreign network domain, an inter-domain AAA procedure is initiated. Since the MR does not have any SA with the AAAL server in the foreign network domain, it should be authenticated with its AAAH server located in its home network domain. The message flows for the inter-domain AAA procedure are depicted in figure 2. Kwon, et al. Expires January 12, 2006 [Page 7] Internet-Draft AAA for NEMO July 2005 MR attendant(AR) AAAL AAAH HA | | | | | | AS | | | | |-------------->| | | | | | | | | | AA | | | | |<--------------| | | | | | | | | | AReq | | | | |-------------->| AMR | | | | |-------------------------->| AMR | | | | |----- >| AHR | | | | |---------->| | | | | | | | | | AHA | | | | AMA |<----------| | | AMA |<------| | | ARep |<--------------------------| | | |<--------------| | | | | | | | | Figure 2. AAA procedures of MR : inter-domain handoff. 1) The MR sends an Attendant Solicit (AS) message to the attendant, i.e. AR. 2) As a response to the AS message, the AR sends an Attendant Advertisement (AA) message including an LC. Even without the AS message, the AR broadcasts AA messages periodically. 3) The MR encrypts the received LC value using the long-term SA with its AAAH server and makes a CR, which is used for the MR's AAAH server to authenticate the MR. Then, the MR sends an AReq message that contains the LC and CR to the attendant. The AReq message also contains the NAI for the AAAL server to identify MR's home domain and the RPI for the MR to protect from replay attack. 4) When the attendant (AR) receives the AReq message, the attendant converts it into an AMR message, which is a new DIAMETER message. And then, the attendant sends the AMR message to the AAAL server in the foreign domain. 5) The AAAL server detects that it cannot authenticate the MR locally by checking the NAI field and hence forwards the AMR message to the MR's AAAH. When the AAAH server receives the AMR message, it decrypts the CR using the pre-established SA and compares the result with the LC value. If these two values are identical, the MR is Kwon, et al. Expires January 12, 2006 [Page 8] Internet-Draft AAA for NEMO July 2005 successfully authenticated. Then, the AAAH server constructs key materials to make two dynamic keys: one is a key_local (to be explained later) for intra-domain AAA procedures in the foreign domain and the other is a key_home to make a secure bi-directional tunnel between the MR and the MR's HA. For the construction of key_local and key_home at the MR, SP_HOME and SP_LOCAL are also generated. These security parameters are encrypted using the long- term key between the MR and AAAH server to avoid the possibility of exposure to other network entities. If there is no HA address in the AMR message, the AAAH server will assign an HA for the MR. 6) The AAAH server informs the HA of the MR's NAI and SP_HOME by the AHR message. 7) The HA constructs key_home by using SP_HOME and replies with an AHA message for confirmation. 8) The AMA message is used for the AAAH server to notify the AAAL server of the AAA result. When the AAAL server receives the AMA message with authentication approval, the AAAL server decrypts the message using the long-term key with the AAAH server, records the MR's NAI, and constructs key_local. 9) The AAAL server will relay the same AMA message from the AAAH server except for the SP_LOCAL to the attendant. 10) When receiving the AMA message, the attendant learns that the MR is authenticated and grants the MR's network access. In addition, the attendant informs the MR of the result by the ARep message containing SP_HOME, SP_LOCAL, home agent address, etc. 4.1.2 Intra-Domain AAA Procedure While a NEMO changes its point of attachment within the same foreign domain, we propose that the MR be authenticated through a localized AAA procedure with the AAAL server in the foreign network without any interaction with the MR's AAAH server. That is, the AAAL of the foreign network can authenticate the MR by the key_local. Kwon, et al. Expires January 12, 2006 [Page 9] Internet-Draft AAA for NEMO July 2005 MR attendant(AR) AAAL | | | | AS | | |-------------->| | | | | | AA | | |<--------------| | | | | | AReq | | |-------------->| AMLR | | |-------------------------->| | | | | | | | | | | | | | | | | | AMLA | | ARep |<--------------------------| |<--------------| | | | | Figure 3. AAA procedures of an MR : intra-domain handoff. Figure 3 illustrates the intra-domain AAA procedure. As a response to the AA message, the VMN sends the AReq message containing CR_L, which is different from CR used in the inter-domain AAA procedure. CR_L is an authentication code generated from the key_local. The attendant constructs an AMLR DIAMETER message and sends it to the AAAL server. When the AAAL server receives the AMLR message, the AAAL server authenticates the MR by using key_local that is already stored at the AAAL server and informs the attendant of the result by the AMLA message. Then, the attendant will relay the result by the ARep message. 4.2 VMN Authentication A VMN is a visiting MN that accesses the Internet through an MR in a NEMO. According to the NEMO basic support protocol [2], the VMN does not need to know whether its new router is the AR or the MR. Therefore, the AAA scheme for VMNs should be also transparent to this issue. In our AAA protocol, the MR serves as an attendant for VMNs and the MR's AAAH server serves as an AAAL server. Accordingly, the VMN will deem the MR to be in the MR's home network. Kwon, et al. Expires January 12, 2006 [Page 10] Internet-Draft AAA for NEMO July 2005 VMN attendant(MR) HA_MR AAAH_MR AAAH_VMN HA_VMN | | | | | | | AS | | | | | |-------------->| | | | | | | | | | | | AA | | | | | |<--------------| | | | | | | | | | | | AReq | | | | | |-------------->| AMR | | | | | |--------------|----- >| | | | | | | AMR | | | | | |---------->| | | | | | | AHR | | | | | |----------->| | | | | | | | | | | |<-----------| | | | | AMA | AHA | | | | |<----------| | | | AMA | | | | | ARep |<-------------|-------| | | |<--------------| | | | | | | | | | | Figure 4. Authentication of a VMN Figure 4 illustrates message flows for the AAA procedure when a VMN is attached to a NEMO. As mentioned above, the MR acts as an attendant. Hence, the MR broadcasts AA messages periodically or responds to an AS message from the VMN with an AS message. The VMN creates CR using the shared SA with its AAAH server VMN and sends an AReq message to the MR. Then, the MR converts the AReq message into a DIAMETER message, AMR, and sends it to the MR's AAAH server AAAH_MR through a secured bi-directional tunnel. When AAAH_MR receives the AMR message, it relays the AMR message to AAAH_VMN that has a shared SA and requests the AAA procedure for the VMN . The AAAH_VMN authenticates the VMN. During this steps, the key_home, key_local, SP_HOME, and SP_LOCAL are created similarly to the inter-domain AAA procedure of the MR. While a NEMO is roaming in a foreign network, VMNs within the NEMO do not need to know that the NEMO changes its point of attachment. Thus, VMNs do not have to register their locations to their HAs when the NEMO hands off. This mobility transparency is the key advantage of the NEMO basic support protocol [2]. While keeping the mobility transparency, the AAAL server of the foreign network cannot detect the existence of VMNs. Even if the mobility transparency is beneficial since it reduces the registration traffic, it makes it Kwon, et al. Expires January 12, 2006 [Page 11] Internet-Draft AAA for NEMO July 2005 hard for the AAAL server to account the network usages of VMNs. We propose that the AAAL server in the foreign domain be able to account the total network usage of the NEMO (not individual VMNs) and then this collective accounting information is sent to the MR's AAAH server. Also, the MR's AAAH server maintains the accounting information for the MR as well as individual VMNs. In NEMO basic support [2], all packets destined to MNNs are tunneled at the MR's HA, so that the MR's HA can keep track of individual LFNs and VMNs. We assume that the MR's HA will report this information to the AAAH server. Consequently, the MR's AAAH server can differentiate the accounting information for MRs and VMNs. In addition, we assume that the MR's AAAH server and the VMN's AAAH server have a trust relationship and a shared SA. Therefore, the accounting information collected at the MR's AAAH server is securely transferred to the VMN's AAAH server. The mobility transparency causes another problem, which is how to authorize VMNs to use the NEMO's network service when the NEMO moves to a foreign domain that has a different billing policy. To solve this problem, an MR sends an AA message requesting re-authentication of VMNs. From the AA message, the VMN determines whether it performs a new AAA procedure or not. In this paper, we assume that each network domain can have a different policy, so that the VMN performs an AAA procedure per inter-domain handoff. 5. References [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work in progress), February 2005. [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Franck, F. and C. Perkins, "Diameter Mobile IPv6 Application", draft-le-aaa-diameter-mobileipv6-04 (work in progress), November 2004. Kwon, et al. Expires January 12, 2006 [Page 12] Internet-Draft AAA for NEMO July 2005 Authors' Addresses Taekyoung Kwon Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9105 Fax: +82-872-2045 Email: tkkwon@snu.ac.kr URI: http://mmlab.snu.ac.kr/~tk/ Sungmin baek Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-9147 Fax: +82-872-2045 Email: smbaek@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~smbaek/ Sangheon Pack Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-1832 Fax: +82-872-2045 Email: shpack@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~shpack/ Kwon, et al. Expires January 12, 2006 [Page 13] Internet-Draft AAA for NEMO July 2005 Yanghee Choi Seoul National University Multimedia and Mobile Communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-7303 Fax: +82-872-2045 Email: yhchoi@snu.ac.kr URI: http://mmlab.snu.ac.kr/~yhchoi/ Kwon, et al. Expires January 12, 2006 [Page 14] Internet-Draft AAA for NEMO July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kwon, et al. Expires January 12, 2006 [Page 15]