IETF Mobile IPv6 Working Group Internet Draft H. Ohnishi Expires: August 2004 M.Yanagiya NTT Y.Ohba Toshiba February 2004 Mobile IPv6 AAA Problem Statement Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Mobile IP achieves that Mobile Node(MN) moves from one subnet to another. If MN moves across different administrative domains in a commercial network, Mobile IPv6 requires AAA's support. This document describes the problem statement to use AAA functions in Mobile IPv6. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [i]. Ohnishi, Ed., et al. Expires - August 2004 [Page 1] MIPv6 AAA problem statement February 2004 Table of Contents 1. Introduction...................................................2 2. AAA usage scenario for Mobile IPv6.............................3 2.1 Roaming to foreign domain..................................3 2.2 Dynamic home address prefix assignment via AAA.............3 2.3 Dynamic HA address assignment via AAA......................3 2.4 Bootstrapping Mobile IPv6 SA from AAA......................3 3. Problem Statement..............................................4 4. Mobile IPv4 AAA solution (informative).........................4 5. Security Consideration.........................................5 Reference.........................................................6 Acknowledgments...................................................6 Author's Addresses................................................7 1. Introduction Mobile IP(v4/v6) [RFC3344][I-D.ietf-mobileip-ipv6] achieves that Mobile Node (MN) moves from one subnet to another. If MN moves across different administrative domains where authentication, authorization and accounting (AAA) is always an issue especially in commercial-based deployments. Mobile IPv4 already defines an interface to AAA functionality [I-D.ietf-mip4-rfc3012bis] [I-D.ietf-aaa-diameter-mobileip] [I-D.ietf-mip4-aaa-nai]. Mobile IPv6 requires an interface to AAA as well. However such an interface has been a missing piece that needs to be filled with an appropriate solution. This document describes several usage cases that deemed necessary to support when Mobile IPv6 is used in an environment where the users subscribe to commercial Mobile IPv6 services with credentials (username, password, certificate, etc.) that are used by the operators as the basis to perform the task of AAA for the Mobile IPv6 services. The usage cases are described in terms of service bootstrapping and security, both are important in large-scale deployments. This document then addresses the fundamental issue that needs to be taken into account when designing an interface between AAA and Mobile IPv6. This document also contains informative description on the approach which is taken by Mobile IPv4 to support AAA, however, it should be noted that the informative description is not advocating or recommending the same approach adopted to Mobile IPv4 to be used for Mobile IPv6. For more information related to IPv6 address assignment in 3GPP, it is recommended to read [RFC3314]. Ohnishi, Ed. et.al Expires - August 2004 [Page 2] MIPv6 AAA problem statement February 2004 2. AAA usage scenario for Mobile IPv6 In this section, we show some application that we are going to solve by using AAA function. 2.1 shows the application to authenticate an MN when the MN accesses to the visiting network. From 2.2 to 2.4 shows service bootstrapping scenarios. Operators may choose a combination of scenarios from these for their services. 2.1 Roaming to foreign domain Mobile IPv6 supports MN's mobility. But if MN moves to a foreign domain, the foreign domain requires the way of Authentication, Authorization and Accounting. RFC2977 shows requirements for this scheme. RFC2977 shows the applications of AAA to the Mobile IP, e.g. the basic model, the local payment model, the local home agent model and so on. 2.2 Dynamic home address prefix assignment via AAA In some cases, operators want to assign home address prefix to mobile node dynamically for the purpose of reducing management cost, etc. Mobile IPv6 prescribes Mobile Prefix Solicitation(MPS) and Mobile Prefix Advertisement(MPA). But in this method, MN needs to know HA address previously. A solution for dynamically and securely assigning home address prefix to mobile node with involving an appropriate authentication and authorization protocol is demanded. 2.3 Dynamic HA address assignment via AAA In some cases, operators want to assign HA to the MN dynamically from the perspective of load balancing. Mobile IPv6 prescribes dynamic HA allocation mechanism in which it sends anycast address to find HA and the HA sends back HAs' list to the MN. HA sends this list without authenticating the MN. A solution for dynamically and securely assigning HA's address to mobile node with involving an appropriate authentication and authorization protocol is demanded. 2.4 Bootstrapping Mobile IPv6 SA from AAA Mobile IPv6 [I-D.ietf-mobileip-ipv6] requires an IPsec SA (Security Association) established between mobile node and its home agent to protect Binding Updates to the home agent. This SA is referred to as Mobile IPv6 SA(MSA). When a home agent is dynamically allocated, it is difficult to assume pre-established security association (such as an IKE [RFC2409] pre-shared secret) between the mobile node and every potential home agent, unless a trusted third-party is involved in the Ohnishi, Ed. et.al Expires - August 2004 [Page 3] MIPv6 AAA problem statement February 2004 authentication procedure between a mobile node and its home agent. Among several alternative models (e.g., Kerberos) that rely on a trusted third-party, there is demand for AAA-based solutions possibly with leveraging the EAP keying framework [I-D.ietf-eap-keying] which allows the key material generated by an EAP authentication algorithm to turn into a credential needed for mutually authenticating mobile node and home agent in the IPsec key management protocol. 3. Problem Statement In Mobile IPv4, AAA for network access service and AAA for Mobile IPv4 service are integrated for optimization purpose. These two types of AAA are different in functionality [I-D.ietf-pana-usage-scenarios], and such an integration is possible in the architecture where an agent that acts as an AAA attendant for both types of AAA is placed in the visiting network. In the case of Mobile IPv4, mobility agent itself (i.e., FA) is such an integrated agent. In Mobile IPv6 architecture, there is no FA unlike Mobile IPv4. The fundamental problem that needs to be solved is to support the usage cases described in Section 2 without introducing FA in Mobile IPv6. This would lead to a need to define a MIPv6 Service Aware AAA Attendant (MSAAA), which is an AAA attendant to provide AAA for Mobile IPv6 service for MN. The MSAAA may be integrated with an AAA attendant of other protocol or service, or may be integrated with MIPv6 home agent, depending on Mobile IPv6 service models. The protocol to transfer information between HA and AAA server is needed in every above MSAAA deployment scenarios. 4. Mobile IPv4 AAA solution (informative) Mobile IPv4 defines two different registration procedures, one via foreign agent that relays the registration to mobile node's home agent, and the other directly with the mobile node's home agent. Both registration procedures involve the exchange of Registration Request and Registration Reply messages. In order to prevent spoofing, Mobile IPv4 defines authentication extension in Registration Request and Reply message [RFC3344]. MN sends Registration Request with authentication extension which includes authenticator to FA or HA. FA or HA evaluates the authenticator by using shared key or public/private key pair. In a large scale roaming service network such as public wireless LAN access service network, it is difficult to distribute all key material to FA and/or HA. Thus, AAA architecture is used to manage key materials of MNs or/and verify credential. Fig 1 shows an example of sequence using RADIUS. It is assumed that MN does not have a security association with FA. MN sends Registration Request which includes challenge value and Network Ohnishi, Ed. et.al Expires - August 2004 [Page 4] MIPv6 AAA problem statement February 2004 Access Identifier (NAI). According to NAI, FA makes a decision on AAA message routing, and passes the authenticator to AAA server. AAA server verifies the authenticator and sends authentication reply. If an authentication is success, FA sends Agent Reply to MN. MN FA AAA |Agent Advertisement | | |[Challenge ext.] | | |<---------------------| | |Registration Request | | |[MN-FA Challenge Ext.,| | | MN-HA Auth. ext., | | | MN-AAA Auth. ext., | | | NAI. ext.] | | |--------------------->| | | |Authentication Request | | |---------------------> | | | | | |Authentication Reply | | |<--------------------- | |Registration Reply | | |(registration accept) | | |<-------------------- | | | | | Figure 1: MN-FA authentication with AAA in Mobile IPv4 In [I-D.ietf-aaa-diameter-mobileip], a similar method is specified by using Diameter application. MN sends Registration Request to FA. FA invokes the local AAA infrastructure (AAAF) to request that a mobile node be authenticated. If AAAF is not aware of the identity of MN, AAAF will forward authentication data to home AAA server (AAAH). 5. Security Consideration This draft identifies a need for bootstrapping Mobile IPv6 by leveraging the AAA infrastructure. Although any solution is not specified in this document, a AAA-based solution for dynamically assigning Mobile IPv6 home agent address is expected to improve Mobile IPv6 security by not relying on the anycast-based scheme built in Mobile IPv6 but relying on the AAA infrastructure instead. More security analysis on bootstrapping MSA should be made when designing a solution. Although security consideration section of [I-D.ietf-eap-keying] covers general security issues for EAP-based service bootstrapping, there may be Mobile IPv6 specific security issues in bootstrapping MSA. Ohnishi, Ed. et.al Expires - August 2004 [Page 5] MIPv6 AAA problem statement February 2004 Reference [RFC3344] C. Perkins, "IP Mobility Support", RFC 3344, August 2002. [I-D.ietf-mobileip-ipv6] Johnson, D., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt, (work in progress), June 30 2003. [I-D.ietf-mip4-rfc3012bis] C. Perkins, et al., "Mobile IPv4 Challenge/Response Extensions (revised)", draft-ietf-mip4-rfc3012bis-00.txt (work in progress), 7 October 2003. [I-D.ietf-aaa-diameter-mobileip] P. Calhoun, et al., "Diameter Mobile IP Application", draft-ietf-aaa-diameter-mobileip-15.txt (work in progress), November 2003. [I-D.ietf-mip4-aaa-nai] F. Johansson and T. Johansson, "Mobile IPv4 Extension for carrying Network Access Identifiers", draft-ietf-mip4-aaa-nai-02.txt (work in progress), December 12, 2003 [RFC3314] M. Wasserman, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [I-D.ietf-pana-usage-scenarios] Y. Ohba, et al., "Problem Statement and Usage Scenarios for PANA", draft-ietf-pana-usage-scenarios-06.txt (work in progress), April 28, 2003. [RFC2977] S. Glass, et al.,"Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [I-D.ietf-eap-keying] Aboba, B., "EAP Key Management Framework", draft-ietf-eap-keying-01 (work in progress), October 2003. [I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-12 (work in progress), January 2004. Acknowledgments We would like to thank Alper Yegin and Rafa Marin Lopez for their valuable contributions to the discussions and preparation of this document. We also would like to thank Basavaraj Patil and Gopal Dommety for their encouraging us to submit this document. Ohnishi, Ed. et.al Expires - August 2004 [Page 6] MIPv6 AAA problem statement February 2004 Author's Addresses Hiroyuki Ohnishi NTT Network service systems laboratories, NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4132 Email: ohnishi.hiroyuki@lab.ntt.co.jp Mayumi Yanagiya NTT Network service systems laboratories, NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6783 Email: yanagiya.mayumi @lab.ntt.co.jp Yoshihiro Ohba Toshiba America Information Systems, Inc. 9740 Irvine Blvd. Irvine, CA 92619-1697 USA Phone: +1 973 829 5174 EMail: yohba@tari.toshiba.com Ohnishi, Ed. et.al Expires - August 2004 [Page 7]