娼タ Network Working Group A. Yegin Internet-Draft Samsung AIT Expires: January 30, 2005 August 2004 AAA Mobile IPv6 Application Framework draft-yegin-mip6-aaa-fwk-00.txt 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 January 30, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a framework for using AAA backend protocols (e.g., RADIUS, Diameter) between home agents and AAA servers for centralizing Mobile IPv6 service management. Implementation of this framework requires definition of a new AAA application on the aforementioned protocols. Yegin Expires January 30, 2005 [Page 1] Internet-Draft MIP6 AAA August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. New AAA Application . . . . . . . . . . . . . . . . . . . . . 8 4. Relation to Mobile IPv6 Bootstrapping . . . . . . . . . . . . 9 5. Other Ways to Talk About Mobile IPv6 and AAA . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 8.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Yegin Expires January 30, 2005 [Page 2] Internet-Draft MIP6 AAA August 2004 1. Introduction AAA backend protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], enable centralized management of authentication, authorization, and accounting (AAA) for a limited type of services (Mobile IPv4 [I-D.ietf-aaa-diameter-mobileip], network access [I-D.ietf-aaa-diameter-nasreq], SIP [I-D.ietf-aaa-diameter-sip-app]). Currently there is no standard mechanism to centralize AAA for Mobile IPv6 [RFC3775]" services. The current Mobile IPv6 protocol design assumes pre-established static configuration between a mobile node (MN, the client) and a home agent (HA, the server) for authentication and authorization of the mobility service. Although there are no standard protocols to retrieve accounting information from a HA yet, SNMP will be useful in the near future with the development of Mobile IPv6 MIBs [I-D.ietf-mip6-mipv6-mib]. The distributed AAA management model could be sufficient in the presence of one static HA per MN, but this is not always the case. In the presence of multiple HAs on a home subnet, reliance on pre-configuration increases the network management overhead. Additionally, there may be more than one home subnet that can be used by a mobile node, in which case the number of possible HAs is further increased. A central AAA infrastructure that is in charge of authentication, authorization, and accounting for the Mobile IPv6 service between any MN and any HA in a domain would benefit deployments by preventing AAA information replication and management across the domain. Furthermore, at times Mobile IPv6 service may have to cross operator domain boundaries. For example, an (serving) operator may wish to provide Mobile IPv6 service to another operator's customers for whom it does not have any per-MN configuration in its local servers. A scalable and secure Mobile IPv6 roaming service [I-D.ietf-mip6-bootstrap-ps] cannot be made possible by solely relying on the HA pre-configuration. The MN can only be authenticated and authorized by an entity in its home operatorどヨs domain. The serving HA has to get in touch with the local AAA infrastructure, which in turn must contact the AAA infrastructure of the home operator. Upon successful authorization and delivery of the service, associated accounting information can be delivered from the serving operator to the home operator. This document describes AAA Mobile IPv6 application framework that enables AAA centralization and roaming for Mobile IPv6 services. There is more than one way to use AAA technologies with Mobile IPv6. The reader should note that the framework advocated in this document Yegin Expires January 30, 2005 [Page 3] Internet-Draft MIP6 AAA August 2004 constitutes only a subset of those possibilities. See Section 5 for more on this subject. Yegin Expires January 30, 2005 [Page 4] Internet-Draft MIP6 AAA August 2004 2. Framework The following figure depicts the interaction among various entities using AAA for Mobile IPv6. Mobile <---------------> Home agent/ <--------------> AAA node Mobile IPv6, AAA client RADIUS or server IKE Diameter Figure 1: MIP6-AAA framework In this framework, Mobile IPv6 protocol is executed between the MN and the HA, as it normally would. Unlike a HA that relies on the preconfigured information, the AAA-enabled HA (more precisely: AAA client on HA) communicates with a AAA server in order to authenticate and authorize the MN before starting the Mobile IPv6 service, and later for making the accounting information available. The current Mobile IPv6 design relies on use of IPsec for authentication of protocol signaling between the MN and the HA. The associated IPsec SA is created by running IKE [RFC3776] between the two. The initial authentication and authorization of MN and HA should be performed during the IKE execution. This is where HA must consult the AAA infrastructure. The authorization at this stage is for establishing an IPsec SA for Mobile IPv6 service. Authorization parameters (e.g., max allowed lifetime) for the subsequent Mobile IPv6 binding updates may also be delivered to the HA at this stage. Upon successful IPsec SA establishment for Mobile IPv6 service, MN can send binding updates to the HA. By the help of IPsec SA, the HA can authenticate the MN without AAA serverどヨs help. Furthermore, the HA can also authorize the binding update if it already has the authorization parameters from its earlier interaction with the AAA server. Otherwise, the HA must contact the AAA server again to perform binding update authorization. Figure 2 is an illustration of a Mobile IPv6 session that starts with IPsec SA establishment and includes one initial and one refreshing binding updates. Yegin Expires January 30, 2005 [Page 5] Internet-Draft MIP6 AAA August 2004 MN HA AAA server | | Auth/Authz for | | IKE | MIPv6 IPsec SA | |<------------------->|<-------------------->| | | | | Binding Update | Authz for BU | |<------------------->|<-------------------->| | | | | | | | | | | Binding Update | Authz for BU | |<------------------->|<-------------------->| | | | v time Figure 2: Message flow Accounting-oriented HA-AAA interaction can take place any time MN is authorized for the service, and it can be piggybacked with the authentication/authorization messaging. This framework is built upon following trust model. (1) (2) HA <------> AAA server <------> MN ^ ^ . . ................................ (3) Figure 3: Trust model It is assumed that HA-AAA (1) and MN-AAA (2) trust relations are pre-configured. HA-AAA may have an indirect trust relation, that spans multiple intermediate server and operator domains. MN-HA (3) trust relation is dynamically created as a result of the AAA interaction. MN can create trust relations with several HAs. These trust relations should not outlive neither the MN-AAA nor the HA-AAA trust relations. An instance of this framework that relies on EAP-based authentication is depicted in Figure 4. Yegin Expires January 30, 2005 [Page 6] Internet-Draft MIP6 AAA August 2004 Mobile <---------------> Home agent/ <--------------> AAA node Mobile IPv6, AAA client EAP/RADIUS server EAP/IKEv2 Figure 4: EAP-based IKE authentication EAP [RFC3748] can provide end-to-end authentication between the MN and AAA server. It can be used for IPsec SA authentication and authorization by being transported on IKEv2 between the MN and HA, and by a AAA-backend protocol between the HA and AAA. EAP framework enables authentication between the peer (MN) and authentication server (AAA server) via an authenticator (HA), and produces a security association between the peer and the authenticator as a result. While the produced security association is not an IPsec SA, it can be used in building one. EAP is not used with Mobile IPv6 binding update authentication and authorization. This framework can also be used with scenarios where other authentication methods (non-EAP-based) are used with IKE. Furthermore, future extensions to Mobile IPv6 specification may involve IPsec/IKEless operation [I-D.ietf-mip6-auth-protocol]. They should readily fit this framework as well. [TBD: Consider using AAA with the CN as well. Now that alternatives to RR-based BU security are being considered, and MN-CN pre-shared key concept is around, leveraging AAA may come into the picture.] Yegin Expires January 30, 2005 [Page 7] Internet-Draft MIP6 AAA August 2004 3. New AAA Application The architectural differences between Mobile IPv4 and Mobile IPv6 necessitate different AAA application framework for each. Mobile IPv4 involves an intermediate server between the MN and the HA, namely foreign agent (FA) which can be co-located with a network access server (NAS). This impacts the end-to-end AAA flow. The signaling authentication is built-in with the Mobile IPv4 protocol, whereas an additional protocol (IPsec) is used for Mobile IPv6. Use of IPsec requires yet another protocol (IKE) for session establishment. This nature of Mobile IPv6 leads to additional authentication and authorization exchanges between the HA and AAA server. The triggering event dictates the nature of exchange (e.g., for authentication and authorization of a Mobile IP IPsec SA creation, vs. authorization of a Mobile IPv6 binding update). In Mobile IPv4, a single interaction between the serving agent (FA or HA) and the AAA server is sufficient to accomplish authentication and authorization of a registration request (equivalent of a Mobile IPv6 binding update). The new AAA application is required to associate a given authorization and accounting to the Mobile IPv6 service. When a AAA client contacts a AAA server, it should be able to convey that the request is for Mobile IPv6 service, as opposed to any other services (network access, SIP, etc.). Additionally, service authorization should take into account parameters like home address and binding lifetime, which are specific to a Mobile IPv6 service. Finally, accounting should support Mobile IPv6-specific MIBs [I-D.ietf-mip6-mipv6-mib]. A formal list of requirements on this interface must be worked out [TBD: future work]. Yegin Expires January 30, 2005 [Page 8] Internet-Draft MIP6 AAA August 2004 4. Relation to Mobile IPv6 Bootstrapping Mobile IPv6 bootstrapping mechanisms [I-D.ietf-mip6-bootstrap-ps] are potentially useful for providing three pieces of information to a MN: HA address or home subnet prefix, home address, and a security association between the MN and HA. The security association does not have to be an IPsec SA, but something that helps creation of an IPsec SA eventually. Use of this framework assumes the MN already knows the HA address. Hence an implementation of this framework cannot help with HA discovery. The security association between MN and HA can be created by using the HA-AAA interface (see EAP-based example). Home address can be obtained before or after running the AAA protocol. For example, the home address may be known by the MN by the time it engages in IKE or Mobile IPv6 with the HA, or it may be dynamically assigned by the HA or the AAA server. An implementation of the framework should work with any of these options. Overall, this framework can be used as part of a Mobile IPv6 bootstrapping operation, but not necessarily as a complete solution to that problem. Yegin Expires January 30, 2005 [Page 9] Internet-Draft MIP6 AAA August 2004 5. Other Ways to Talk About Mobile IPv6 and AAA Talking about AAA does not make sense without specifying the associated service. There is a difference between AAA for network access and AAA for Mobile IPv6 services [8]. This distinction may be blurry in certain cases (e.g., when Mobile IPv4 authentication is used for network access as well), but otherwise they are at least logically separate services. There are several ways to mix the keywords ど」Mobile IPv6ど・ with ど」AAAど・ in addition the one described in this document. They are listed here for the sake of identification, but not necessarily for advocating them. (a) Using network access AAA to deliver Mobile IPv6 bootstrapping information directly to a node (MN) [I-D.giaretta-mip6-authorization-eap][I-D.le-aaa-mipv6-requirements] [I-D.ohnishi-mip6-aaa-problem-statement]. (b) Using network access AAA to deliver Mobile IPv6 bootstrapping information to the network access server (NAS) [I-D.chowdhury-mip6-bootstrap-radius]. It is assumed that the information is delivered from NAS to the MN via some additional protocol [I-D.jang-dhc-haopt] (c) Piggybacking Mobile IPv6 signaling with network access AAA [I-D.le-aaa-mipv6-requirements] This approach assumes that the AAA servers for network access and Mobile IPv6 services are the same. Yegin Expires January 30, 2005 [Page 10] Internet-Draft MIP6 AAA August 2004 6. Security Considerations The framework defined in this document is aligned with the AAA backend protocols and the existing AAA applications. Therefore there are no new security considerations stemming from the general framework. Details of the authorization are Mobile IPv6 specific. Exact parameters, their semantics and processing details must be described in an implementation of this framework. Yegin Expires January 30, 2005 [Page 11] Internet-Draft MIP6 AAA August 2004 7. Acknowledgements Thanks to Kent Leung and Alpesh Patel for useful feedback. Yegin Expires January 30, 2005 [Page 12] Internet-Draft MIP6 AAA August 2004 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2 Informative References [I-D.chowdhury-mip6-bootstrap-radius] Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile IPv6 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-00 (work in progress), July 2004. [I-D.giaretta-mip6-authorization-eap] Giaretta, G., "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-01 (work in progress), July 2004. [I-D.ietf-aaa-diameter-mobileip] Calhoun, P., Johansson, T., Perkins, C. and T. Hiller, "Diameter Mobile IPv4 Application", draft-ietf-aaa-diameter-mobileip-20 (work in progress), August 2004. [I-D.ietf-aaa-diameter-nasreq] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter Network Access Server Application", draft-ietf-aaa-diameter-nasreq-17 (work in progress), July 2004. [I-D.ietf-aaa-diameter-sip-app] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C. and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", draft-ietf-aaa-diameter-sip-app-03 (work in progress), July 2004. [I-D.ietf-mip6-auth-protocol] "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth-protocol-00 (work in progress), July 2004. [I-D.ietf-mip6-bootstrap-ps] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. Yegin Expires January 30, 2005 [Page 13] Internet-Draft MIP6 AAA August 2004 [I-D.ietf-mip6-mipv6-mib] Keeni, G., Nagami, K., Koide, K. and S. Gundavelli, "A Management Information Base for Mobile IPv6", draft-ietf-mip6-mipv6-mib-03 (work in progress), July 2004. [I-D.jang-dhc-haopt] Yegin, A., "DHCP Option for Home Agent Discovery in MIPv6", draft-jang-dhc-haopt-00 (work in progress), June 2004. [I-D.le-aaa-mipv6-requirements] Faccin, S., "Mobile IPv6 Authentication, Authorization, and Accounting Requirements", draft-le-aaa-mipv6-requirements-03 (work in progress), February 2004. [I-D.ohnishi-mip6-aaa-problem-statement] Ohnishi, H., "Mobile IPv6 AAA Problem Statement", draft-ohnishi-mip6-aaa-problem-statement-00 (work in progress), February 2004. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. Yegin Expires January 30, 2005 [Page 14] Internet-Draft MIP6 AAA August 2004 Author's Address Alper E. Yegin Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA Phone: +1 408 544 5656 EMail: alper.yegin@samsung.com Yegin Expires January 30, 2005 [Page 15] Internet-Draft MIP6 AAA August 2004 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 (2004). 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. Yegin Expires January 30, 2005 [Page 16]