RFC 3141

CDMA2000 Wireless Data Requirements for AAA

📅 published June 2001, from ietf

RFC 3141: CDMA2000 Wireless Data Requirements for AAA ✨

okay bestie, this one is a Network Working Group doc from June 2001 🦋 It's Informational, which means it gives info to the Internet community and doesn't set any standard. The header doesn't list anything it obsoletes or updates.

The author squad is massive 💅

  • T. Hiller, Lucent Technologies
  • P. Walsh, Lucent Technologies
  • X. Chen, Alcatel
  • M. Munson (no affiliation listed)
  • 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

Status of This Memo 🌸

This memo is here to give info to the Internet community 🫶 It doesn't specify any kind of Internet standard. Distribution is unlimited, so share it with your whole group chat 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract ✨

This memo lays out the cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements for third generation wireless architecture. That architecture supports roaming between service providers for traditional PPP and Mobile IP services 🎀

1. Introduction ✨

The architecture is built to use a cellular network as its access medium 📱 Sections 1 and 2 are a quick, high level tour of the cdma2000 wireless data architecture, there to help AAA WG members get oriented. Section 3 covers the cdma2000 AAA requirements, and it stands on its own, so you don't need the architecture review to read it 🦋

This document is all about the AAA requirements for a third generation cdma2000 wireless architecture that supports roaming between service providers for traditional PPP and Mobile IP services. Once again, the architecture is designed for a cellular network as the access medium 💖

1.1. Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" get read the way [RFC2119] describes them 🧚

Heads up, the requirements in this doc are meant for judging AAA protocol submissions. So the requirements language is talking about what those protocols can do. The protocol docs themselves will say whether each feature is required, recommended, or optional. For example, requiring a protocol to support confidentiality is not the same thing as requiring all protocol traffic to be encrypted 🔐

A protocol submission isn't compliant if it misses even one of the MUST or MUST NOT requirements for the capabilities it implements. A submission that meets every MUST, MUST NOT, SHOULD and SHOULD NOT requirement for its capabilities is called "unconditionally compliant" 👑 A submission that meets all the MUST and MUST NOT requirements, but not every SHOULD or SHOULD NOT requirement for its protocols, is called "conditionally compliant." Still valid, just a little less iconic 💅

1.2. General Service Requirements

  • Provide service while a subscriber is visiting between wireless network systems, and keep a formal customer-service provider relationship with only one wireless service provider 🌸
  • Support traditional PPP and Mobile IP services:
    • Support dynamic and static home address assignments for Mobile IP
    • Support a Home Agent in the mobile's home wireless network, home ISP, or private network
    • Support IP Security on the Mobile IP tunnel between the Foreign Agent and Home Agent, so you don't pay the overhead of a voluntary tunnel on the radio interface 🛡️
  • Provide robust authentication, authorization and accounting services (AAA):
    • Keep airlink resource AAA services separate from data resource AAA services
    • Authenticate and authorize a mobile based on an IMSI and an NAI. The architecture lets a carrier decide whether billing is based on the IMSI or the NAI 💸
    • Support optional AAA broker services between wireless carriers, and between wireless carriers and other external data networks
    • Allow distribution of specific Mobile IP security key information to support home agent assignment, fast handoff, and fast HA-FA authentication assignment during registration 🔑
  • Provide QoS 🎀

2. High Level Architecture 🌈

The high level architecture is shown in Figure 1. Six major entities make up the network: the Home Agent, the PDSN, the AAA Server, the Radio Network, the HLR/VLR, and the 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 📐

2.1. PDSN

  • Acts as a Foreign Agent
  • Establishes, maintains, and terminates the link layer to the mobile client
  • Kicks off the authentication, authorization and accounting for the mobile client
  • Optionally, securely tunnels using IP security to the Home Agent
  • Receives service parameters from AAA for the mobile client
  • Collects usage data for accounting purposes, to be relayed to AAA 📊
  • Routes packets to external packet data networks, or to the HA in the case of reverse tunneling
  • Maps the home address and Home Agent address to a unique link layer identifier used to communicate with the Radio Network

2.2. Authentication, Authorization, and Accounting Server 👑

  • Works with the Foreign Agent and other AAA servers to authorize, authenticate, and do accounting for the mobile client
  • Provides a mechanism to support security associations between PDSN/FA and HA, and between the MN and PDSN/FA
  • For dynamic Home Agent assignment, dynamically identifies an HA, assigns an MN to that HA, and provides the security association between the MN and HA
  • Provides QoS information to the PDSN
  • Optionally, assigns a dynamic home address

2.3. Radio Network 📡

  • Maps a Mobile Client identifier reference to a unique link layer identifier used to communicate with the PDSN
  • Validates the Mobile Station for access service
  • Manages the physical layer connection to the Mobile Client
  • Maintains the state of reachability for packet service between the access radio network and the mobile station
  • Buffers packets arriving from the PDSN when radio resources are not in place or are insufficient to support the flow from the PDSN
  • Relays packets between the mobile station and the PDSN

2.4. Location Registers (VLR/HLR) 🗂️

  • Stores authentication and authorization information for the radio network

2.5. Home Agent 🏠

  • Maintains user registration and redirects packets to the PDSN
  • Optionally, establishes an IP secure tunnel to the PDSN/FA
  • Supports dynamic Home Agent assignment
  • Optionally, assigns a dynamic home address
  • Supports reverse tunneling

2.6. Mobile Node 📱

  • Supports PPP
  • Can act as a Mobile IP Node, and supports Foreign Agent Challenge and NAI
  • Interacts with the Radio Network to obtain appropriate radio resources from the network for exchanging packets
  • Maintains knowledge of the status of radio resources (e.g., active, standby, dormant) 🔋
  • Buffers packets when radio resources are not in place or are insufficient to support the flow to the network

3. AAA Requirements ✨

Section 3 is the main event, so part 2 picks up right here 💖

3.1. Core AAA Requirements ✨

okay so here's the cdma2000 AAA wishlist 💅 The serving network and home network might or might not have a direct business relationship. If they don't, service can still happen indirectly through a broker 🫶

  • Authenticate and authorize a user NAI while roaming 🦋 The NAI comes from CHAP (for regular PPP service) or a Foreign Agent Challenge (for Mobile IP service). There's a shared secret between the mobile and its HAAA, and the FAC will typically be computed in a way that's consistent with CHAP.
  • Carry wireless data attributes from the home network over to the serving network 🎀 This is often a user profile.
  • Encrypt or sign one or more AVPs in an AAA message between home, serving network, or some broker, even across multiple AAA server hops 🔒
  • Support a reliable AAA transport mechanism 💖
    • This transport mechanism will be able to tell an AAA application that a message got delivered to the next peer AAA application, or that a timeout happened 🫧
    • Retransmission is handled by the reliable AAA transport mechanism, not by lower layer protocols like TCP. no cap, that's the whole point 🙅‍♀️
    • Even if the AAA message is getting forwarded, or its options or semantics don't follow the AAA protocol, the transport mechanism will still acknowledge that the peer received the message. BUT if the message fails authentication, it won't be acknowledged 😤
    • Acknowledgements should be allowed to ride along (piggybacked) in AAA messages 🌸
    • The reliable transport features shall have the capability to detect silent failures of the AAA peer or the path to it, so failures get managed proactively 👀
    • Transport a digital certificate in an AAA message, so there are fewer round trips per AAA transaction 🧚 Note: This requirement applies to AAA applications and not mobile stations.
    • Support both proxy and non-proxy brokers. A non-proxy broker terminates an entire request and starts a new one. AAA brokers should be able to modify certain parts of AAA messages so they can work in both non-proxy and proxy environments 🔄
  • Provide message integrity and identity authentication on a per hop (AAA node) basis 🛡️
  • Support replay protection and optional non-repudiation for all authorization and accounting messages 💜 The AAA protocol must be able to match accounting messages with prior authorization messages.
  • Support accounting through bilateral arrangements and through broker AAA servers that act as an accounting clearinghouse and handle reconciliation between serving and home networks 💸 There's an explicit agreement that if the private network or home ISP authenticates the mobile station requesting service, then that private network or home ISP also agrees to reconcile charges with the home service provider or broker. Real time accounting must be supported ⏱️
  • Provide security between AAA servers, and between an AAA server and a PDSN or HA, via IP security 🔐

3.2. Mobile IP Specific Requirements and AAA 🌈

3.2.1. Mobile IP Security Discussion

three Mobile IP security extensions are defined in RFC 2002, and they're basically the three pairs:

. HA - FA
. MN - FA
. HA - MN

so Mobile IP and IPsec security models are different, lowkey the big difference. Mobile IP brings its own authentication mechanisms, calculated inside the Mobile IP registration procedures, whereas IPsec uses IPsec AH 🧠

the keys and SPIs for the MN-FA and HA-FA extensions need to be dynamically established in a roaming wireless carrier environment 🌍 The MN-FA extension helps a new FA (PDSN) quickly authenticate a mobile by using the previous foreign agent extension. The HA-FA extension helps the HA make sure that only FAs from carriers with roaming agreements can access the HA. The MN-HA is usually provisioned, but for dynamic Home Agent assignment, this security association has to be dynamically created ✨

it's possible to use IPsec AH between MN and FA, FA and HA, and MN and HA. IKE may be used to set up security associations between these entities. However, IKE may pose a problem for smaller mobiles and may introduce unacceptable delays for certain applications (for example, Voice Over IP) 🙈 The next three sections outline Mobile IP specific functions that benefit from AAA based key distribution 🎀

3.2.2. Dynamic Home Agent Assignment

a visited or home AAA server will optionally be able to perform dynamic HA assignment 🦋 For a dynamically assigned HA, the visited AAA server tells the home AAA server whether it supports dynamic HA assignment in cases where the mobile node requests dynamic assignment. If it's indicated, the home AAA server may choose to let the visited AAA server do the HA assignment. Otherwise, the home AAA assigns the HA 💅

3.2.3. Fast Handoff

to get a faster handoff, the mobile may try to avoid an AAA transaction with the home AAA server ⚡ To do that, the mobile may send the PDSN the Previous FA address in the RRQ message from the mobile, along with the MN-FA authentication extension. The new PDSN passes the Previous FA address and the MN-FA authentication extension to the visited AAA server. If the visited AAA server is able to authenticate the MN-FA authentication extension for the mobile, then the visited AAA may be able to skip an actual transaction to the home AAA server 🫶

3.2.4. HA-FA Authentication

for a fast registration when a mobile station has a Home Agent, the PDSN and HA may receive a HA-FA key and SPI from the AAA mechanism 🔑 They use it to authenticate the PDSN and the HA to each other 💖

3.2.5. Key Distribution

this stuff is mainly useful in a wireless environment where handoffs can happen rapidly (which means low latency is a must 🏃‍♀️), or where mobile devices have limited computing power 📱 To make it work, AAA will be used to securely pass keys and SPIs between the serving network and target network, in encrypted form 🔐 These keys are then used for the specific functions outlined in this document 🌸

3.3. IKE and AAA 🧚

the use of IKE in the cdma2000 wireless architecture requires certificates 📜 However, the AAA servers may be able to distribute a pre-shared key to the Mobile IP Agents for use during Phase 1 ISAKMP exchanges. This may lessen the need for online revocation checks 💜

3.4. Interoperability with RADIUS 🍓

users with a home AAA server based on RADIUS may want to roam into a wireless carrier network that uses "new" AAA servers based on the requirements in this document, and vice versa 🔄 The AAA protocol should be designed so that conversions to and from RADIUS messages are straightforward. That lets people build gateway processes to help with interoperability 🛠️ Note: The features of the new AAA protocols that go beyond the feature set of the RADIUS protocol will not be available to users on home or serving networks that are based on RADIUS 🥲

4. References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 📚

5. Security Considerations 🔥

this document is very much about security 🔐 These requirements do not require the serving and home networks to be outside the same domain, and they don't have to have a direct relationship either. The serving network needs authorization from the home network so it gets proof it'll be paid for services it provided to the mobile. That implies the home network must authenticate the user. AAA functions must be performed in a secure manner. The requirements in section 2 outline the security that's required 🛡️

Mobile IP supports authentication mechanisms that sit outside IP Security. These mechanisms may be enhanced in a cellular wireless environment by letting a home AAA server distribute keys to the serving network. The home AAA server may also 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 be sent in encrypted form from the home network to the serving network. As supported in the requirements in section 2, the encryption could be handled via public cryptography and certificates 🌈

6. IANA Considerations

this document does not create any new number spaces for IANA administration 📭

7. Acknowledgements 🫶

the authors are active members of the TIA TR45.6 committee 🎀

8. Authors' Addresses ✨

okay bestie, here are all the amazing people who wrote this RFC 🫶 every single one of them gets their contact info listed, no cap 💖

Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
USA

Phone: (650) 786-7733
EMail: pcalhoun@eng.sun.com


Ed Campbell
CommWorks Corporation, A 3Com Company
3800 Golf Road
Rolling Meadows, IL 60008

Phone: (847)262-2325
E-Mail: ed_campbell@commworks.com
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA

EMail: gdommety@cisco.com


Tom Hiller
Rm 2F-218
263 Shuman Dr.
Lucent Technologies
Naperville, IL
USA

Phone: (630) 979-7673
EMail: tom.hiller@lucent.com


Raymond T. Hsu
Qualcomm Inc.
6455 Lusk Blvd.
San Diego, CA 92121
USA

Phone: (619) 651-3623
EMail: rhsu@qualcomm.com


Mark A. Lipford
Sprint PCS
15405 College Blvd.
Lenexa, KS  66219

Phone:  (913) 890-4248
EMail: mlipfo01@sprintspectrum.com


Serge Manning
Award Solutions, Inc.
800 E. Campbell Rd., Suite 120
Richardson, TX  75081

Phone: (972) 664-0727 x350
EMail: serge@awardsolutions.com
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566
USA

Phone: (630) 713 9359
EMail: mccap@lucent.com


Mark Munson
1371 Winding Branch Circle
Atlanta, Georgia 30338
USA

Phone: (678) 339-4439
EMail: mmunson@gte.net


Haeng Koo
Samsung Telecommunications America, Inc.
1130 E. Arapaho Road
Richardson, TX 75081
USA

Phone: (972)761-7755
EMail: hskoo@sta.samsung.com


Pat Walsh
Lucent Technologies
263 Shuman Blvd.
1F-545
Naperville, IL

Phone: +1 630-713-5063
EMail: walshp@lucent.com
Yingchun Xu
WaterCove Networks
One Century Centre, Suite 550
1750 E. Golf Road
Schaumburg, IL

Phone: +1 847-477-9280
EMail: yxu@watercove.com


Brent Hirschman
1501 Shure Dr.
Arlington Heights, IL 60006
USA

Phone: (847) 632-1563
EMail: qa4053@email.mot.com


Eric Jaques
Vodafone
2999 Oak Road, MS-750
Walnut Creek, CA 94596
USA

Phone: +1-925-210-3900
EMail: ejaques@akamail.com


Sanjeevan Sivalingham
Ericsson Wireless Communications Inc.,
Rm Q-356C
6455 Lusk Blvd
San Diego, CA 92126
USA

Phone: (858) 332-5670
EMail:  s.sivalingham@ericsson.com
Xing Chen
Alcatel USA
1000 Coit Road
Plano, TX 75075
USA

Phone: 972-519-4142
Fax:   +1 972-519-3300
EMail: xing.chen@usa.alcatel.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: bklim@lge.com


Hajime Shiino
Lucent Technologies Japan Ltd.
25 Mori Bldg. 1-4-30 Roppongi,
Minato-ku Tokyo
Japan

Phone: +81-3-5561-3695
EMail: hshiino@lucent.com


Shinichi Baba
Toshiba America Research, Inc.
PO Box 136,
Convent Station, NJ 07961-0136
USA

Phone: (973) 829-4795
EMail: sbaba@tari.toshiba.com
Takahiro Ayaki
DDI corporation
Ichibancho FS Bldg.
8, Ichibancho, Chiyoda-ku Tokyo
Japan

Phone: +81-3-3221-9682
EMail: ayaki@ddi.co.jp


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: t-seki@kddi.com

legal stuff time, but it's still important 💅 The Internet Society owns the copyright here, so this is the official notice, kept complete:

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. 🫶

📦 where this page comes from