rfc3141.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/2 页
TXT
900 行
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.
Abstract
This 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.
Hiller, et al. Informational [Page 1]
RFC 3141 CDMA2000 Wireless Data Requirements June 2001
1. Introduction
The architecture is designed for use with a cellular network as an
access medium. 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.
1.1. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [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."
1.2. General Service Requirements
o Provide service during subscriber visiting between wireless
networks systems while maintaining a formal customer-service
provider relation with only one wireless service provider.
o Support Traditional PPP and Mobile IP services:
Hiller, et al. Informational [Page 2]
RFC 3141 CDMA2000 Wireless Data Requirements June 2001
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
Hiller, et al. Informational [Page 3]
RFC 3141 CDMA2000 Wireless Data Requirements June 2001
2. High Level Architecture
The high level architecture is shown in 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
Hiller, et al. Informational [Page 4]
RFC 3141 CDMA2000 Wireless Data Requirements June 2001
2.1. PDSN
o Acts as a Foreign Agent;
o Establish, maintain, and terminate link layer to the mobile
client;
o Initiate the authentication, authorization and accounting for
the mobile client;
o Optionally, securely tunnel using IP security to the Home
Agent;
o Receives service parameters from AAA for mobile client;
o Collect usage data for accounting purposes to be relayed to
AAA;
o Routes packets to external packet data networks or to the HA in
the case of reverse tunneling;
o Maps home address and Home Agent address to a unique link layer
identifier used to communicate with Radio Network.
2.2. Authentication, Authorization, and Accounting Server
o Interact with the Foreign Agent and other AAA servers to
authorize, authenticate and perform accounting for the mobile
client;
o Provides mechanism to support security association between
PDSN/FA and HA and between the MN and PDSN/FA;
o For dynamic Home Agent assignment, dynamically identify an HA
and assign a MN on that HA, and provide the security
association between the MN and HA;
o Provide QoS information to the PDSN;
o Optionally, assign dynamic home address.
2.3. Radio Network
o Maps Mobile Client identifier reference to a unique link layer
identifier used to communicate with PDSN;
o Validates Mobile Station for access service;
o Manages physical layer connection to the Mobile Client;
o Maintain state of reachability for packet service between the
access radio network and the mobile station;
o Buffers packets arriving from the PDSN, when radio resources
are not in place or are insufficient to support the flow from
the PDSN;
o Relays packets between the mobile station and the PDSN.
2.4. Location Registers (VLR/HLR)
o Stores authentication and authorization information for the
radio network.
Hiller, et al. Informational [Page 5]
RFC 3141 CDMA2000 Wireless Data Requirements June 2001
2.5. Home Agent
o Maintains user registration and redirects packets to the PDSN;
o Optionally, establish an IP secure tunnel to the PDSN/FA;
o Supports the dynamic Home Agent assignment;
o Optionally, assigns dynamic home address;
o Support reverse tunneling.
2.6. Mobile Node
o Support PPP;
o Can act as a Mobile IP Node; and support Foreign Agent
Challenge and NAI;
o Interacts with the Radio Network to obtain appropriate radio
resources from the network for the exchange of packets;
o Maintains knowledge of status of radio resources (e.g., active,
standby, dormant);
o Buffers packets when radio resources are not in place or are
insufficient to support the flow to the network.
3. AAA Requirements
3.1. Core AAA Requirements
The following is a summary of cdma2000 AAA specific requirements. In
these requirements, the serving network and home network may or may
not have a direct business relationship. In such cases in which
there is not a direct business relationship, service may be supported
indirectly via broker.
o Authenticate and authorize a user NAI in a roaming environment.
The NAI is obtained via CHAP (for traditional PPP service) or a
Foreign Agent Challenge (for Mobile IP service). A shared
secret exists between the mobile and its HAAA. The FAC will
typically be computed in a manner consistent with CHAP.
o Transport wireless data attributes from the home network to the
Serving network. This may often take the form of a user
profile.
o Encrypt or sign one or more AVPs in an AAA message between
home, serving network, or some broker across multiple AAA
server hops.
o Support a reliable AAA transport mechanism.
o This transport mechanism will be able indicate to an AAA
application that a message was delivered to the next peer
AAA application or that a time out occurred.
o Retransmission is controlled by the reliable AAA transport
mechanism, and not by lower layer protocols such as TCP.
Hiller, et al. Informational [Page 6]
RFC 3141 CDMA2000 Wireless Data Requirements June 2001
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.
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:
. HA - FA
. MN - FA
. HA - MN
Hiller, et al. Informational [Page 7]
RFC 3141 CDMA2000 Wireless Data Requirements June 2001
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.
3.2.2. Dynamic Home Agent Assignment
A visited or home AAA server will optionally be able perform dynamic
HA assignment. For dynamically assigned HA, the visited AAA server
will indicate to the home AAA server whether it supports dynamic HA
assignment in those cases in which the mobile node requests dynamic
assignment. If so indicated, the home AAA server may choose to allow
the visited AAA server to perform the HA assignment. Otherwise, the
home AAA assigns the HA.
3.2.3. Fast Handoff
To achieve a faster handoff, the mobile may attempt to avoid an AAA
transaction with the home AAA server. To accomplish this, 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 MN-FA authentication extension to
the visited AAA server. If the visited AAA server is able
authenticate the MN-FA authentication extension for the mobile, then
the visited AAA may be able to avoid an actual transaction to the
home AAA server.
Hiller, et al. Informational [Page 8]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?