Network Working Group T. Hiller, Lucent Technologies Request for Comments: 3141 P. Walsh, Lucent Technologies Category: Informational X. Chen, Alcatel M. Munson G. Dommety, Cisco Systems S. Sivalingham, Ericsson Wireless Communications B. Lim, LG Information & Communications, Ltd. P. McCann, Lucent Technologies H. Shiino, Lucent Technologies B. Hirschman, Motorola S. Manning, Award Solutions, Inc. R. Hsu, Qualcomm, Inc. H. Koo, Samsung Telecommunications America, Inc. M. Lipford, Sprint PCS P. Calhoun, Sun Laboratories, Inc. C. Lo, Vodafone E. Jaques, Vodafone E. Campbell, CommWorks Corporation, A 3Com Company Y. Xu, WaterCove Networks S. Baba, Toshiba America Research, Inc. T. Ayaki, DDI Corporation T. Seki, DO Corporation A. Hameed, Fujitsu June 2001 CDMA2000 Wireless Data Requirements for AAA Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services.
Sections 1, 2, present a brief high level review of the cdma2000 wireless data architecture. Section 3 presents cdma2000 AAA requirements. This document specifies AAA requirements associated with a third generation cdma2000 wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. The architecture is designed for use with a cellular network as an access medium. Sections 1 and 2 present a brief, high level review of the cdma2000 wireless data architecture as an aid to interested AAA WG members. Section 3 presents cdma2000 AAA requirements, and is self contained relative to the architecture review. RFC2119]. Please note that the requirements specified in this document are to be used in evaluating AAA protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted. A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant."
o Support dynamic and static home address assignments for Mobile IP o Support a Home Agent in the mobile's home wireless network, home ISP, or private network. o Support IP Security on the Mobile IP tunnel between Foreign Agent and Home Agent, in order to avoid the overhead of a voluntary tunnel on the radio interface. o Provide robust authentication, authorization and accounting services (AAA): o Provide separation of airlink resource AAA services and data resource AAA services. o Authenticate and authorize a mobile based on an IMSI and an NAI. The architecture allows for a carrier to determine if billing is based on the IMSI or the NAI. o Support optional AAA broker services between wireless carriers and between wireless carriers and other external data networks. o Allow for distribution of specific Mobile IP security key information to support home agent assignment, fast handoff, and fast HA-FA authentication assignment during registration. o Provide QoS
Figure 1. The six major entities that compose the network are the Home Agent, the PDSN, the AAA Server, the Radio Network, the HLR/VLR, and Mobile Client. Visited Access Home Access Provider Network Provider Network +--------+ +--------+ | | SS7 | | | VLR |-----------------| HLR | | | | | +--------+ +--------+ | | | Visited Access Broker Home IP | Provider Network Network Network | +--------+ +--------+ +--------+ | | | | | | | | | AAA |------| AAA |---| AAA | | | | | | | | | +--------+ +--------+ +--------+ | \ \ | | \ \ | | \ \ | | \ \ | | \ \ | +---------+ +---------+ +---------+ | | | | | | | RN |-------| PDSN |-------| HA | | | | | | | +---------+ +---------+ +---------+ | | Visited Access Home Network | Provider Network -Private Mobile| -Visited Provider IP | -Home Provider | -Home ISP +--------+ | Mobile | | Node | +--------+ Figure 1: General cdma2000 Wireless IP Architecture
o Even if the AAA message is to be forwarded, or the message's options or semantics do not conform with the AAA protocol, the transport mechanism will acknowledge that the peer received the AAA message. However, if the message fails to pass authentication, it will not be acknowledged. o Acknowledgements should be allowed to be piggybacked in AAA messages o The reliable transport mechanism features shall have the capability to detect silent failures of the AAA peer or path to the AAA peer, to manage failure on a proactive basis. o Transport a digital certificate in an AAA message, in order to minimize the number of round trips associated with AAA transactions. Note: This requirement applies to AAA applications and not mobile stations. o Support both proxy and non-proxy brokers, where non-proxy brokers imply the broker terminates an entire request and initiates a new request. AAA brokers should have the capability to modify certain parts of AAA messages whereby to operate to in non-proxy or proxy environments. o Provide message integrity and identity authentication on a per hop (AAA node) basis. o Support replay protection and optional non-repudiation capabilities for all authorization and accounting messages. The AAA protocol must provide the capability for accounting messages to be matched with prior authorization messages. o Support accounting via both bilateral arrangements and via broker AAA servers providing accounting clearinghouse and reconciliation between serving and home networks. There is an explicit agreement that if the private network or home ISP authenticates the mobile station requesting service, then the private network or home ISP network also agrees to reconcile charges with the home service provider or broker. Real time accounting must be supported. o Provides security between AAA servers, and between AAA server and PDSN or HA via IP security. RFC 2002: . HA - FA . MN - FA . HA - MN
Therefore, Mobile IP and IPsec security models differ in that Mobile IP provides its own authentication mechanisms calculated within the Mobile IP registration procedures whereas IPsec uses IPsec AH. The keys and SPIs associated with the MN-FA and HA-FA extensions need to be dynamically established in a roaming wireless carrier environment. The MN-FA extension is useful for allowing a new FA (PDSN) to quickly authenticate a mobile using the previous foreign agent extension. The HA-FA extension is useful for the HA to ensure that only FAs from carrier's with roaming agreements access the HA. The MN-HA is usually provisioned, but for dynamic Home Agent assignment, this security association must be dynamically created. It is possible to use IPsec AH between MN and FA, FA and HA, and MN and HA. IKE may be used to establish security associations between these entities. However, use of IKE may pose a problem for smaller mobiles and may introduce unacceptable delays for certain applications (e.g., Voice Over IP). The following three sections outline Mobile IP specific functions that benefit from AAA based key distribution.
network obtains proof it will get paid for services rendered to the mobile. This implies the home network must authenticate the user. AAA functions must be performed in a secure manner. The requirements contained in section 2 outline the security required. Mobile IP supports authentication mechanisms outside IP Security. These mechanism may be enhanced in a cellular wireless environment by allowing a home AAA server to distribute keys to the serving network. Additionally, the home AAA server may be able to send a pre-shared key to be used in Phase 1 ISAKMP security association establishment between FA and HA. These keys would sent in encrypted form from the home network to the serving network. As supported in the requirements contained in section 2, the encryption could be handled via public cryptography and certificates.
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: firstname.lastname@example.org Tom Hiller Rm 2F-218 263 Shuman Dr. Lucent Technologies Naperville, IL USA Phone: (630) 979-7673 EMail: email@example.com Raymond T. Hsu Qualcomm Inc. 6455 Lusk Blvd. San Diego, CA 92121 USA Phone: (619) 651-3623 EMail: firstname.lastname@example.org Mark A. Lipford Sprint PCS 15405 College Blvd. Lenexa, KS 66219 Phone: (913) 890-4248 EMail: email@example.com Serge Manning Award Solutions, Inc. 800 E. Campbell Rd., Suite 120 Richardson, TX 75081 Phone: (972) 664-0727 x350 EMail: firstname.lastname@example.org
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA Phone: (630) 713 9359 EMail: email@example.com Mark Munson 1371 Winding Branch Circle Atlanta, Georgia 30338 USA Phone: (678) 339-4439 EMail: firstname.lastname@example.org Haeng Koo Samsung Telecommunications America, Inc. 1130 E. Arapaho Road Richardson, TX 75081 USA Phone: (972)761-7755 EMail: email@example.com Pat Walsh Lucent Technologies 263 Shuman Blvd. 1F-545 Naperville, IL Phone: +1 630-713-5063 EMail: firstname.lastname@example.org
Yingchun Xu WaterCove Networks One Century Centre, Suite 550 1750 E. Golf Road Schaumburg, IL Phone: +1 847-477-9280 EMail: email@example.com Brent Hirschman 1501 Shure Dr. Arlington Heights, IL 60006 USA Phone: (847) 632-1563 EMail: firstname.lastname@example.org Eric Jaques Vodafone 2999 Oak Road, MS-750 Walnut Creek, CA 94596 USA Phone: +1-925-210-3900 EMail: email@example.com Sanjeevan Sivalingham Ericsson Wireless Communications Inc., Rm Q-356C 6455 Lusk Blvd San Diego, CA 92126 USA Phone: (858) 332-5670 EMail: firstname.lastname@example.org
Xing Chen Alcatel USA 1000 Coit Road Plano, TX 75075 USA Phone: 972-519-4142 Fax: +1 972-519-3300 EMail: email@example.com Byung-Keun Lim LG Electronics Inc. 533, Hogye-dong, Donan-Ku, Anyang-shi, Kyungki-do, 431-080, Korea Phone: +82-31-450-7199 Fax: +82-31-450-7050 EMail: firstname.lastname@example.org Hajime Shiino Lucent Technologies Japan Ltd. 25 Mori Bldg. 1-4-30 Roppongi, Minato-ku Tokyo Japan Phone: +81-3-5561-3695 EMail: email@example.com Shinichi Baba Toshiba America Research, Inc. PO Box 136, Convent Station, NJ 07961-0136 USA Phone: (973) 829-4795 EMail: firstname.lastname@example.org
Takahiro Ayaki DDI corporation Ichibancho FS Bldg. 8, Ichibancho, Chiyoda-ku Tokyo Japan Phone: +81-3-3221-9682 EMail: email@example.com Alan Hameed Fujitsu 2801 Telecom Parkway Richardson, Texas 75082 USA Phone: (972) 479-2089 Charles N. Lo Vodafone AirTouch 2999 Oak Rd Walnut Creek, CA 94596 USA Phone: (925) 210-3460 EMail: Charles.Lo@vodafone-us.com Takuo Seki IDO Corporation Gobancho YS Bldg. 12-3, Gobancho, Chiyoda-ku Tokyo Japan Phone: +81-3-3263-9660 EMail: firstname.lastname@example.org
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.