summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2977.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2977.txt')
-rw-r--r--doc/rfc/rfc2977.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc2977.txt b/doc/rfc/rfc2977.txt
new file mode 100644
index 0000000..d75aec7
--- /dev/null
+++ b/doc/rfc/rfc2977.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group S. Glass
+Request for Comments: 2977 Sun Microsystems
+Category: Informational T. Hiller
+ Lucent Technologies
+ S. Jacobs
+ GTE Laboratories
+ C. Perkins
+ Nokia Research Center
+ October 2000
+
+
+ Mobile IP Authentication, Authorization, and Accounting Requirements
+
+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 (2000). All Rights Reserved.
+
+Abstract
+
+ The Mobile IP and Authentication, Authorization, Accounting (AAA)
+ working groups are currently looking at defining the requirements for
+ Authentication, Authorization, and Accounting. This document
+ contains the requirements which would have to be supported by a AAA
+ service to aid in providing Mobile IP services.
+
+1. Introduction
+
+ Clients obtain Internet services by negotiating a point of attachment
+ to a "home domain", generally from an ISP, or other organization from
+ which service requests are made, and fulfilled. With the increasing
+ popularity of mobile devices, a need has been generated to allow
+ users to attach to any domain convenient to their current location.
+ In this way, a client needs access to resources being provided by an
+ administrative domain different than their home domain (called a
+ "foreign domain"). The need for service from a foreign domain
+ requires, in many models, Authorization, which leads directly to
+ Authentication, and of course Accounting (whence, "AAA"). There is
+ some argument which of these leads to, or is derived from the others,
+ but there is common agreement that the three AAA functions are
+ closely interdependent.
+
+
+
+
+
+Glass, et al. Informational [Page 1]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ An agent in a foreign domain, being called on to provide access to a
+ resource by a mobile user, is likely to request or require the client
+ to provide credentials which can be authenticated before access to
+ resources is permitted. The resource may be as simple as a conduit
+ to the Internet, or may be as complex as access to specific private
+ resources within the foreign domain. Credentials can be exchanged in
+ many different ways, all of which are beyond the scope of this
+ document. Once authenticated, the mobile user may be authorized to
+ access services within the foreign domain. An accounting of the
+ actual resources may then be assembled.
+
+ Mobile IP is a technology that allows a network node ("mobile node")
+ to migrate from its "home" network to other networks, either within
+ the same administrative domain, or to other administrative domains.
+ The possibility of movement between domains which require AAA
+ services has created an immediate demand to design and specify AAA
+ protocols. Once available, the AAA protocols and infrastructure will
+ provide the economic incentive for a wide-ranging deployment of
+ Mobile IP. This document will identify, describe, and discuss the
+ functional and performance requirements that Mobile IP places on AAA
+ protocols.
+
+ The formal description of Mobile IP can be found in [13,12,14,17].
+
+ In this document, we have attempted to exhibit requirements in a
+ progressive fashion. After showing the basic AAA model for Mobile
+ IP, we derive requirements as follows:
+
+ - requirements based on the general model
+ - requirements based on providing IP service for mobile nodes
+ - requirements derived from specific Mobile IP protocol needs
+
+ Then, we exhibit some related AAA models and describe requirements
+ derived from the related models.
+
+2. Terminology
+
+ This document frequently uses the following terms in addition to
+ those defined in RFC 2002 [13]:
+
+ Accounting The act of collecting information on resource usage
+ for the purpose of trend analysis, auditing, billing,
+ or cost allocation.
+
+
+
+
+
+
+
+
+Glass, et al. Informational [Page 2]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ Administrative Domain
+ An intranet, or a collection of networks, computers,
+ and databases under a common administration.
+ Computer entities operating in a common
+ administration may be assumed to share
+ administratively created security associations.
+
+ Attendant A node designed to provide the service interface
+ between a client and the local domain.
+
+ Authentication
+ The act of verifying a claimed identity, in the form
+ of a pre-existing label from a mutually known name
+ space, as the originator of a message (message
+ authentication) or as the end-point of a channel
+ (entity authentication).
+
+ Authorization
+ The act of determining if a particular right, such as
+ access to some resource, can be granted to the
+ presenter of a particular credential.
+
+ Billing The act of preparing an invoice.
+
+ Broker An intermediary agent, trusted by two other AAA
+ servers, able to obtain and provide security services
+ from those AAA servers. For instance, a broker may
+ obtain and provide authorizations, or assurances that
+ credentials are valid.
+
+ Client A node wishing to obtain service from an attendant
+ within an administrative domain.
+
+ Foreign Domain
+ An administrative domain, visited by a Mobile IP
+ client, and containing the AAA infrastructure needed
+ to carry out the necessary operations enabling Mobile
+ IP registrations. From the point of view of the
+ foreign agent, the foreign domain is the local
+ domain.
+
+ Inter-domain Accounting
+ Inter-domain accounting is the collection of
+ information on resource usage of an entity with an
+ administrative domain, for use within another
+ administrative domain. In inter-domain accounting,
+ accounting packets and session records will typically
+ cross administrative boundaries.
+
+
+
+Glass, et al. Informational [Page 3]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ Intra-domain Accounting
+ Intra-domain accounting is the collection of
+ information on resource within an administrative
+ domain, for use within that domain. In intra-domain
+ accounting, accounting packets and session records
+ typically do not cross administrative boundaries.
+
+ Local Domain
+ An administrative domain containing the AAA
+ infrastructure of immediate interest to a Mobile IP
+ client when it is away from home.
+
+ Real-time Accounting
+ Real-time accounting involves the processing of
+ information on resource usage within a defined time
+ window. Time constraints are typically imposed in
+ order to limit financial risk.
+
+ Session record
+ A session record represents a summary of the resource
+ consumption of a user over the entire session.
+ Accounting gateways creating the session record may
+ do so by processing interim accounting events.
+
+ In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+ "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
+ described in [4].
+
+3. Basic Model
+
+ In this section, we attempt to capture the main features of a basic
+ model for operation of AAA servers that seems to have good support
+ within the Mobile IP working group. Within the Internet, a client
+ belonging to one administrative domain (called the home domain) often
+ needs to use resources provided by another administrative domain
+ (called the foreign domain). An agent in the foreign domain that
+ attends to the client's request (call the agent the "attendant") is
+ likely to require that the client provide some credentials that can
+ be authenticated before access to the resources is permitted. These
+ credentials may be something the foreign domain understands, but in
+ most cases they are assigned by, and understood only by the home
+ domain, and may be used for setting up secure channels with the
+ mobile node.
+
+
+
+
+
+
+
+
+Glass, et al. Informational [Page 4]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ Local Domain Home Domain
+ +--------------+ +----------------------+
+ | +------+ | | +------+ |
+ | | | | | | | |
+ | | AAAL | | | | AAAH | |
+ | | +-------------------+ | |
+ | +---+--+ | | +------+ |
+ | | | | |
+ | | | +----------------------+
+ +------+ | +---+--+ |
+ | | | | | | C = client
+ | C |- -|- -| A | | A = attendant
+ | | | | | | AAAL = local authority
+ +------+ | +------+ | AAAH = home authority
+ | |
+ +--------------+
+
+ Figure 1: AAA Servers in Home and Local Domains
+
+ The attendant often does not have direct access to the data needed to
+ complete the transaction. Instead, the attendant is expected to
+ consult an authority (typically in the same foreign domain) in order
+ to request proof that the client has acceptable credentials. Since
+ the attendant and the local authority are part of the same
+ administrative domain, they are expected to have established, or be
+ able to establish for the necessary lifetime, a secure channel for
+ the purposes of exchanging sensitive (access) information, and
+ keeping it private from (at least) the visiting mobile node.
+
+ The local authority (AAAL) itself may not have enough information
+ stored locally to carry out the verification for the credentials of
+ the client. In contrast to the attendant, however, the AAAL is
+ expected to be configured with enough information to negotiate the
+ verification of client credentials with external authorities. The
+ local and the external authorities should be configured with
+ sufficient security relationships and access controls so that they,
+ possibly without the need for any other AAA agents, can negotiate the
+ authorization that may enable the client to have access to any/all
+ requested resources. In many typical cases, the authorization
+ depends only upon secure authentication of the client's credentials.
+
+ Once the authorization has been obtained by the local authority, and
+ the authority has notified the attendant about the successful
+ negotiation, the attendant can provide the requested resources to the
+ client.
+
+
+
+
+
+
+Glass, et al. Informational [Page 5]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ In the picture, there might be many attendants for each AAAL, and
+ there might be many clients from many different Home Domains. Each
+ Home Domain provides a AAAH that can check credentials originating
+ from clients administered by that Home Domain.
+
+ There is a security model implicit in the above figure, and it is
+ crucial to identify the specific security associations assumed in the
+ security model.
+
+ First, it is natural to assume that the client has a security
+ association with the AAAH, since that is roughly what it means for
+ the client to belong to the home domain.
+
+ Second, from the model illustrated in figure 1 it is clear that AAAL
+ and AAAH have to share a security association, because otherwise they
+ could not rely on the authentication results, authorizations, nor
+ even the accounting data which might be transacted between them.
+ Requiring such bilateral security relationships is, however, in the
+ end not scalable; the AAA framework MUST provide for more scalable
+ mechanisms, as suggested below in section 6.
+
+ Finally, in the figure, it is clear that the attendant can naturally
+ share a security association with the AAAL. This is necessary in
+ order for the model to work because the attendant has to know that it
+ is permissible to allocate the local resources to the client.
+
+ As an example in today's Internet, we can cite the deployment of
+ RADIUS [16] to allow mobile computer clients to have access to the
+ Internet by way of a local ISP. The ISP wants to make sure that the
+ mobile client can pay for the connection. Once the client has
+ provided credentials (e.g., identification, unique data, and an
+ unforgeable signature), the ISP checks with the client's home
+ authority to verify the signature, and to obtain assurance that the
+ client will pay for the connection. Here, the attendant function can
+ be carried out by the NAS, and the local and home authorities can use
+ RADIUS servers. Credentials allowing authorization at one attendant
+ SHOULD be unusable in any future negotiations at the same or any
+ other attendant.
+
+ From the description and example above, we can identify several
+ requirements.
+
+ - Each local attendant has to have a security relationship with the
+ local AAA server (AAAL)
+ - The local authority has to share, or dynamically establish,
+ security relationships with external authorities that are able to
+ check client credentials
+
+
+
+
+Glass, et al. Informational [Page 6]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ - The attendant has to keep state for pending client requests while
+ the local authority contacts the appropriate external authority
+ - Since the mobile node may not necessarily initiate network
+ connectivity from within its home domain, it MUST be able to
+ provide complete, yet unforgeable credentials without ever having
+ been in touch with its home domain.
+ - Since the mobile node's credentials have to remain unforgeable,
+ intervening nodes (e.g., neither the attendant or the local
+ authority (AAAL) or any other intermediate nodes) MUST NOT be able
+ to learn any (secret) information which may enable them to
+ reconstruct and reuse the credentials.
+
+ From this last requirement, we can see the reasons for the natural
+ requirement that the client has to share, or dynamically establish, a
+ security relationship with the external authority in the Home Domain.
+ Otherwise, it is technically infeasible (given the implied network
+ topology) for the client to produce unforgeable signatures that can
+ be checked by the AAAH. Figure 2 illustrates the natural security
+ associations we understand from our proposed model. Note that,
+ according to the discussion in section 6, there may, by mutual
+ agreement between AAAL and AAAH, be a third party inserted between
+ AAAL and AAAH to help them arbitrate secure transactions in a more
+ scalable fashion.
+
+ +------+ +------+
+ | | | |
+ | AAAL +--------------+ AAAH |
+ | | | |
+ +---+--+ +--+---+
+ | |
+ | |
+ +---+--+ +--+---+
+ C = client | | | |
+ A = attendant | A | | C |
+ AAAL = local authority | | | |
+ AAAH = home authority +------+ +------+
+
+ Figure 2: Security Associations
+
+ In addition to the requirements listed above, we specify the
+ following requirements which derive from operational experience with
+ today's roaming protocols.
+
+ - There are scenarios in which an attendant will have to manage
+ requests for many clients at the same time.
+ - The attendant MUST protect against replay attacks.
+
+
+
+
+
+Glass, et al. Informational [Page 7]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ - The attendant equipment should be as inexpensive as possible,
+ since it will be replicated as many times as possible to handle as
+ many clients as possible in the foreign domain.
+ - Attendants SHOULD be configured to obtain authorization, from a
+ trusted local AAA server (AAAL) for Quality of Service
+ requirements placed by the client.
+
+ Nodes in two separate administrative domains (for instance, AAAH and
+ AAAL) often must take additional steps to verify the identity of
+ their communication partners, or alternatively to guarantee the
+ privacy of the data making up the communication. While these
+ considerations lead to important security requirements, as mentioned
+ above in the context of security between servers, we consider the
+ exact choice of security associations between the AAA servers to be
+ beyond the scope of this document. The choices are unlikely even to
+ depend upon any specific features of the general model illustrated in
+ figure 1. On the other hand, the security associations needed
+ between Mobile IP entities will be of central importance in the
+ design of a suitable AAA infrastructure for Mobile IP. The general
+ model shown above is generally compatible with the needs of Mobile
+ IP. However, some basic changes are needed in the security model of
+ Mobile IP, as detailed in section 5.
+
+ Lastly, recent discussion in the mobile-ip working group has
+ indicated that the attendant MUST be able to terminate service to the
+ client based on policy determination by either AAAH or AAAL server.
+
+3.1. AAA Protocol Roaming Requirements
+
+ In this section we will detail additional requirements based on
+ issues discovered through operational experience of existing roaming
+ RADIUS networks. The AAA protocol MUST satisfy these requirements in
+ order for providers to offer a robust service. These requirements
+ have been identified by TR45.6 as part of their involvement with the
+ Mobile IP working group.
+
+ - Support a reliable AAA transport mechanism.
+ * There must be an effective hop-by-hop retransmission and
+ failover mechanism so that reliability does not solely depend
+ on end-to-end retransmission
+ * 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.
+ * Retransmission is controlled by the reliable AAA transport
+ mechanism, and not by lower layer protocols such as TCP.
+
+
+
+
+
+
+Glass, et al. Informational [Page 8]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ * 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.
+ * Acknowledgements SHOULD be allowed to be piggybacked in AAA
+ messages
+ * AAA responses have to be delivered in a timely fashion so that
+ Mobile IP does not timeout and retransmit
+ - 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. The certificates could be used by
+ foreign and home agents to establish an IPSec security association
+ to secure the mobile node's tunneled data. In this case, the AAA
+ infrastructure could assist by obtaining the revocation status of
+ such a certificate (either by performing online checks or
+ otherwise validating the certificate) so that home and foreign
+ agents could avoid a costly online certificate status check.
+ - Provide message integrity and identity authentication on a hop-
+ by-hop (AAA node) basis.
+ - 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.
+ - 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.
+ Timestamps must be included in all accounting packets.
+
+4. Requirements related to basic IP connectivity
+
+ The requirements listed in the previous section pertain to the
+ relationships between the functional units, and don't depend on the
+ underlying network addressing. On the other hand, many nodes (mobile
+ or merely portable) are programmed to receive some IP-specific
+ resources during the initialization phase of their attempt to connect
+ to the Internet.
+
+ We place the following additional requirements on the AAA services in
+ order to satisfy such clients.
+
+ - Either AAA server MUST be able to obtain, or to coordinate the
+ allocation of, a suitable IP address for the customer, upon
+ request by the customer.
+
+
+
+Glass, et al. Informational [Page 9]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ - AAA servers MUST be able to identify the client by some means
+ other than its IP address.
+
+ Policy in the home domain may dictate that the home agent instead of
+ the AAAH manages the allocation of an IP address for the mobile node.
+ AAA servers MUST be able to coordinate the allocation of an IP
+ address for the mobile node at least in this way.
+
+ AAA servers today identify clients by using the Network Access
+ Identifier (NAI) [1]. A mobile node can identify itself by including
+ the NAI along with the Mobile IP Registration Request [6]. The NAI
+ is of the form "user@realm"; it is unique and well suited for use in
+ the AAA model illustrated in figure 1. Using a NAI (e.g.,
+ "user@realm") allows AAAL to easily determine the home domain (e.g.,
+ "realm") for the client. Both the AAAL and the AAAH can use the NAI
+ to keep records indexed by the client's specific identity.
+
+5. AAA for Mobile IP
+
+ Clients using Mobile IP require specific features from the AAA
+ services, in addition to the requirements already mentioned in
+ connection with the basic AAA functionality and what is needed for IP
+ connectivity. To understand the application of the general model for
+ Mobile IP, we consider the mobile node (MN) to be the client in
+ figure 1, and the attendant to be the foreign agent (FA). If a
+ situation arises that there is no foreign agent present, e.g., in the
+ case of an IPv4 mobile node with a co-located care of address or an
+ IPv6 mobile node, the equivalent attendant functionality is to be
+ provided by the address allocation entity, e.g., a DHCP server. Such
+ an attendant functionality is outside the scope of this document.
+ The home agent, while important to Mobile IP, is allowed to play a
+ role during the initial registration that is subordinate to the role
+ played by the AAAH. For application to Mobile IP, we modify the
+ general model (as illustrated in figure 3). After the initial
+ registration, the mobile node is authorized to continue using Mobile
+ IP at the foreign domain without requiring further involvement by the
+ AAA servers. Thus, the initial registration will probably take
+ longer than subsequent Mobile IP registrations.
+
+ In order to reduce this extra time overhead as much as possible, it
+ is important to reduce the time taken for communications between the
+ AAA servers. A major component of this communications latency is the
+ time taken to traverse the wide-area Internet that is likely to
+ separate the AAAL and the AAAH. This leads to a further strong
+ motivation for integration of the AAA functions themselves, as well
+ as integration of AAA functions with the initial Mobile IP
+ registration. In order to reduce the number of messages that
+ traverse the network for initial registration of a Mobile Node, the
+
+
+
+Glass, et al. Informational [Page 10]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ AAA functions in the visited network (AAAL) and the home network
+ (AAAH) need to interface with the foreign agent and the home agent to
+ handle the registration message. Latency would be reduced as a
+ result of initial registration being handled in conjunction with AAA
+ and the mobile IP mobility agents. Subsequent registrations,
+ however, would be handled according to RFC 2002 [13]. Another way to
+ reduce latency as to accounting would be the exchange of small
+ records.
+
+ As there are many different types of sub-services attendants may
+ provide to mobile clients, there MUST be extensible accounting
+ formats. In this way, the specific services being provided can be
+ identified, as well as accounting support should more services be
+ identified in the future.
+
+ The AAA home domain and the HA home domain of the mobile node need
+ not be part of the same administrative domain. Such an situation can
+ occur if the home address of the mobile node is provided by one
+ domain, e.g., an ISP that the mobile user uses while at home, and the
+ authorization and accounting by another (specialized) domain, e.g., a
+ credit card company. The foreign agent sends only the authentication
+ information of the mobile node to the AAAL, which interfaces to the
+ AAAH. After a successful authorization of the mobile node, the
+ foreign agent is able to continue with the mobile IP registration
+ procedure. Such a scheme introduces more delay if the access to the
+ AAA functionality and the mobile IP protocol is sequentialized.
+ Subsequent registrations would be handled according to RFC 2002 [13]
+ without further interaction with the AAA. Whether to combine or
+ separate the Mobile IP protocol data with/from the AAA messages is
+ ultimately a policy decision. A separation of the Mobile IP protocol
+ data and the AAA messages can be successfully accomplished only if
+ the IP address of the mobile node's home agent is provided to the
+ foreign agent performing the attendant function.
+
+ All needed AAA and Mobile IP functions SHOULD be processed during a
+ single Internet traversal. This MUST be done without requiring AAA
+ servers to process protocol messages sent to Mobile IP agents. The
+ AAA servers MUST identify the Mobile IP agents and security
+ associations necessary to process the Mobile IP registration, pass
+ the necessary registration data to those Mobile IP agents, and remain
+ uninvolved in the routing and authentication processing steps
+ particular to Mobile IP registration.
+
+ For Mobile IP, the AAAL and the AAAH servers have the following
+ additional general tasks:
+
+ - enable [re]authentication for Mobile IP registration
+
+
+
+
+Glass, et al. Informational [Page 11]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ - authorize the mobile node (once its identity has been established)
+ to use at least the set of resources for minimal Mobile IP
+ functionality, plus potentially other services requested by the
+ mobile node
+ - initiate accounting for service utilization
+ - use AAA protocol extensions specifically for including Mobile IP
+ registration messages as part of the initial registration sequence
+ to be handled by the AAA servers.
+
+ These tasks, and the resulting more specific tasks to be listed later
+ in this section, are beneficially handled and expedited by the AAA
+ servers shown in figure 1 because the tasks often happen together,
+ and task processing needs access to the same data at the same time.
+
+ Local Domain Home Domain
+ +--------------+ +----------------------+
+ | +------+ | | +------+ |
+ | | | | | | | |
+ | | AAAL | | | | AAAH | |
+ | | +-------------------+ | |
+ | +---+--+ | | +--+---+ |
+ | | | | | |
+ | | | | | |
+ +------+ | +---+--+ | | +--+---+ |
+ | | | | | | | | | |
+ | MN +- -|- -+ FA + -- -- -- -- - + HA | |
+ | | | | | | | | | |
+ +------+ | +------+ | | +------+ |
+ | | | |
+ +--------------+ +----------------------+
+
+
+ Figure 3: AAA Servers with Mobile IP agents
+
+ In the model in figure 1, the initial AAA transactions are handled
+ without needing the home agent, but Mobile IP requires every
+ registration to be handled between the home agent (HA) and the
+ foreign agent (FA), as shown by the sparse dashed (lower) line in
+ figure 3. This means that during the initial registration, something
+ has to happen that enables the home agent and foreign agent to
+ perform subsequent Mobile IP registrations. After the initial
+ registration, the AAAH and AAAL in figure 3 would not be needed, and
+ subsequent Mobile IP registrations would only follow the lower
+ control path between the foreign agent and the home agent.
+
+ Any Mobile IP data that is sent by FA through the AAAL to AAAH MUST
+ be considered opaque to the AAA servers. Authorization data needed
+ by the AAA servers then MUST be delivered to them by the foreign
+
+
+
+Glass, et al. Informational [Page 12]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ agent from the data supplied by the mobile node. The foreign agent
+ becomes a translation agent between the Mobile IP registration
+ protocol and AAA.
+
+ As mentioned in section 3, nodes in two separate administrative
+ domains often must take additional steps to guarantee their security
+ and privacy,, as well as the security and privacy of the data they
+ are exchanging. In today's Internet, such security measures may be
+ provided by using several different algorithms. Some algorithms rely
+ on the existence of a public-key infrastructure [8]; others rely on
+ distribution of symmetric keys to the communicating nodes [9]. AAA
+ servers SHOULD be able to verify credentials using either style in
+ their interactions with Mobile IP entities.
+
+ In order to enable subsequent registrations, the AAA servers MUST be
+ able to perform some key distribution during the initial Mobile IP
+ registration process from any particular administrative domain.
+
+ This key distribution MUST be able to provide the following security
+ functions:
+
+ - identify or create a security association between MN and home
+ agent (HA); this is required for the MN to produce the
+ [re]authentication data for the MN--HA authentication extension,
+ which is mandatory on Mobile IP registrations.
+ - identify or create a security association between mobile node and
+ foreign agent, for use with subsequent registrations at the same
+ foreign agent, so that the foreign agent can continue to obtain
+ assurance that the same mobile node has requested the continued
+ authorization for Mobile IP services.
+ - identify or create a security association between home agent and
+ foreign agent, for use with subsequent registrations at the same
+ foreign agent, so that the foreign agent can continue to obtain
+ assurance that the same home agent has continued the authorization
+ for Mobile IP services for the mobile node.
+ - participate in the distribution of the security association (and
+ Security Parameter Index, or SPI) to the Mobile IP entities
+ - The AAA server MUST also be able to validate certificates provided
+ by the mobile node and provide reliable indication to the foreign
+ agent.
+ - The AAAL SHOULD accept an indication from the foreign agent about
+ the acceptable lifetime for its security associations with the
+ mobile node and/or the mobile node's home agent. This lifetime
+ for those security associations SHOULD be an integer multiple of
+ registration lifetime offered by the foreign agent to the mobile
+ node. This MAY allow for Mobile IP reauthentication to take place
+
+
+
+
+
+Glass, et al. Informational [Page 13]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ without the need for reauthentication to take place on the AAA
+ level, thereby shortenning the time required for mobile node
+ reregistration.
+ - The AAA servers SHOULD be able to condition their acceptance of a
+ Mobile IP registration authorization depending upon whether the
+ registration requires broadcast or multicast service to the mobile
+ node tunneled through the foreign agent.
+ - In addition, reverse tunneling may also be a necessary requirement
+ for mobile node connectivity. Therefore, AAA servers SHOULD also
+ be able to condition their acceptance of Mobile IP registration
+ authorization depending upon whether the registration requires
+ reverse tunnelling support to the home domain through the foreign
+ agent.
+
+ The lifetime of any security associations distributed by the AAA
+ server for use with Mobile IP SHOULD be great enough to avoid too-
+ frequent initiation of the AAA key distribution, since each
+ invocation of this process is likely to cause lengthy delays between
+ [re]registrations [5]. Registration delays in Mobile IP cause
+ dropped packets and noticeable disruptions in service. Note that any
+ key distributed by AAAH to the foreign agent and home agent MAY be
+ used to initiate Internet Key Exchange (IKE) [7].
+
+ Note further that the mobile node and home agent may well have a
+ security association established that does not depend upon any action
+ by the AAAH.
+
+5.1. Mobile IP with Dynamic IP Addresses
+
+ According to section 4, many people would like their mobile nodes to
+ be identified by their NAI, and to obtain a dynamically allocated
+ home address for use in the foreign domain. These people may often
+ be unconcerned with details about how their computers implement
+ Mobile IP, and indeed may not have any knowledge of their home agent
+ or any security association except that between themselves and the
+ AAAH (see figure 2). In this case the Mobile IP registration data
+ has to be carried along with the AAA messages. The AAA home domain
+ and the HA home domain have to be part of the same administrative
+ domain.
+
+ Mobile IP requires the home address assigned to the mobile node
+ belong to the same subnet as the Home Agent providing service to the
+ mobile node. For effective use of IP home addresses, the home AAA
+ (AAAH) SHOULD be able to select a home agent for use with the newly
+ allocated home address. In many cases, the mobile node will already
+ know the address of its home agent, even if the mobile node does not
+ already have an existing home address. Therefore, the home AAA
+ (AAAH) MUST be able to coordinate the allocation of a home address
+
+
+
+Glass, et al. Informational [Page 14]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ with a home agent that might be designated by the mobile node.
+
+ Allocating a home address and a home agent for the mobile would
+ provide a further simplification in the configuration needs for the
+ client's mobile node. Currently, in the Proposed Standard Mobile IP
+ specification [13] a mobile node has to be configured with a home
+ address and the address of a home agent, as well as with a security
+ association with that home agent. In contrast, the proposed AAA
+ features would only require the mobile node to be configured with its
+ NAI and a secure shared secret for use by the AAAH. The mobile
+ node's home address, the address of its home agent, the security
+ association between the mobile node and the home agent, and even the
+ identity (DNS name or IP address) of the AAAH can all be dynamically
+ determined as part of Mobile IP initial registration with the
+ mobility agent in the foreign domain (i.e., a foreign agent with AAA
+ interface features). Nevertheless, the mobile node may choose to
+ include the MN-HA security extension as well as AAA credentials, and
+ the proposed Mobile IP and AAA server model MUST work when both are
+ present.
+
+ The reason for all this simplification is that the NAI encodes the
+ client's identity as well as the name of the client's home domain;
+ this follows existing industry practice for the way NAIs are used
+ today (see section 4). The home domain name is then available for
+ use by the local AAA (AAAL) to locate the home AAA serving the
+ client's home domain. In the general model, the AAAL would also have
+ to identify the appropriate security association for use with that
+ AAAH. Section 6 discusses a way to reduce the number of security
+ associations that have to be maintained between pairs of AAA servers
+ such as the AAAL and AAAH just described.
+
+5.2. Firewalls and AAA
+
+ Mobile IP has encountered some deployment difficulties related to
+ firewall traversal; see for instance [11]. Since the firewall and
+ AAA server can be part of the same administrative domain, we propose
+ that the AAA server SHOULD be able to issue control messages and keys
+ to the firewall at the boundary of its administrative domain that
+ will configure the firewall to be permeable to Mobile IP registration
+ and data traffic from the mobile node.
+
+
+
+
+
+
+
+
+
+
+
+Glass, et al. Informational [Page 15]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+5.3. Mobile IP with Local Home Agents
+
+ +-------------------------+ +--------------+
+ | +------+ +------+ | | +------+ |
+ | | | | | | | | | |
+ | | HA +----+ AAAL | | | | AAAH | |
+ | | | | +-------------------+ | |
+ | +-+----+ +---+--+ | | +------+ |
+ | | | | | Home Domain |
+ | | +- - - - - + | +--------------+
+ +------+ | +-+--+-+ |
+ | | | | | |
+ | MN +------+ FA | |
+ | | | | | Local Domain |
+ +------+ | +------+ |
+ +-------------------------+
+
+ Figure 4: Home Agent Allocated by AAAL
+
+ In some Mobile IP models, mobile nodes boot on subnets which are
+ technically foreign subnets, but the services they need are local,
+ and hence communication with the home subnet as if they were residing
+ on the home is not necessary. As long as the mobile node can get an
+ address routable from within the current domain (be it publicly, or
+ privately addressed) it can use mobile IP to roam around that domain,
+ calling the subnet on which it booted its temporary home. This
+ address is likely to be dynamically allocated upon request by the
+ mobile node.
+
+ In such situations, when the client is willing to use a dynamically
+ allocated IP address and does not have any preference for the
+ location of the home network (either geographical or topological),
+ the local AAA server (AAAL) may be able to offer this additional
+ allocation service to the client. Then, the home agent will be
+ located in the local domain, which is likely to be offer smaller
+ delays for new Mobile IP registrations.
+
+ In figure 4, AAAL has received a request from the mobile node to
+ allocate a home agent in the local domain. The new home agent
+ receives keys from AAAL to enable future Mobile IP registrations.
+ From the picture, it is evident that such a configuration avoids
+ problems with firewall protection at the domain boundaries, such as
+ were described briefly in section 5.2. On the other hand, this
+ configuration makes it difficult for the mobile node to receive data
+ from any communications partners in the mobile node's home
+ administrative domain. Note that, in this model, the mobile node's
+ home address is affiliated with the foreign domain for routing
+ purposes. Thus, any dynamic update to DNS, to associate the mobile
+
+
+
+Glass, et al. Informational [Page 16]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ node's home FQDN (Fully Qualified Domain Name [10]) with its new IP
+ address, will require insertion of a foreign IP address into the home
+ DNS server database.
+
+5.4. Mobile IP with Local Payments
+
+ Since the AAAL is expected to be enabled to allocate a local home
+ agent upon demand, we can make a further simplification. In cases
+ where the AAAL can manage any necessary authorization function
+ locally (e.g., if the client pays with cash or a credit card), then
+ there is no need for an AAA protocol or infrastructure to interact
+ with the AAAH. The resulting simple configuration is illustrated in
+ figure 5.
+
+ In this simplified model, we may consider that the role of the AAAH
+ is taken over either by a national government (in the case of a cash
+ payment), or by a card authorization service if payment is by credit
+ card, or some such authority acceptable to all parties. Then, the
+ AAAL expects those external authorities to guarantee the value
+ represented by the client's payment credentials (cash or credit).
+ There are likely to be other cases where clients are granted access
+ to local resources, or access to the Internet, without any charges at
+ all. Such configurations may be found in airports and other common
+
+ +-------------------------+
+ | +------+ +------+ |
+ | | | | | |
+ | | HA +----+ AAAL | |
+ | | | | | |
+ | +--+---+ +----+-+ |
+ | | | |
+ | +- - - - - + | |
+ +------+ | +-+--+-+ |
+ | | | | | |
+ | MN +- -|- - - - - - - + FA | |
+ | | | Local Domain | | |
+ +------+ | +------+ |
+ +-------------------------+
+
+ Figure 5: Local Payment for Local Mobile IP services
+
+ areas where business clients are likely to spend time. The service
+ provider may find sufficient reward in the goodwill of the clients,
+ or from advertisements displayed on Internet portals that are to be
+ used by the clients. In such situations, the AAAL SHOULD still
+ allocate a home agent, appropriate keys, and the mobile node's home
+ address.
+
+
+
+
+Glass, et al. Informational [Page 17]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+5.5. Fast Handover
+
+ Since the movement from coverage area to coverage area may be
+ frequent in Mobile IP networks, it is imperative that the latency
+ involved in the handoff process be minimized. See, for instance, the
+ Route Optimization document [15] for one way to do this using Binding
+ Updates. When the mobile node enters a new visited subnet, it would
+ be desirable for it to provide the previous foreign agent's NAI. The
+ new FA can use this information to either contact the previous FA to
+ retrieve the KDC session key information, or it can attempt to
+ retrieve the keys from the AAAL. If the AAAL cannot provide the
+ necessary keying information, the request will have to be sent to the
+ mobile node's AAAH to retrieve new keying information. After initial
+ authorization, further authorizations SHOULD be done locally within
+ the Local Domain.
+
+ When a MN moves into a new foreign subnet as a result of a handover
+ and is now served by a different FA, the AAAL in this domain may
+ contact the AAAL in the domain that the MN has just been handed off
+ from to verify the authenticity of the MN and/or to obtain the
+ session keys. The new serving AAAL may determine the address of the
+ AAAL in the previously visited domain from the previous FA NAI
+ information supplied by the MN.
+
+6. Broker Model
+
+ The picture in Figure 1 shows a configuration in which the local and
+ the home authority have to share trust. Depending on the security
+ model used, this configuration can cause a quadratic growth in the
+ number of trust relationships, as the number of AAA authorities (AAAL
+ and AAAH) increases. This has been identified as a problem by the
+ roamops working group [3], and any AAA proposal MUST solve this
+ problem. Using brokers solves many of the scalability problems
+ associated with requiring direct business/roaming relationships
+ between every two administrative domains. In order to provide
+ scalable networks in highly diverse service provider networks in
+ which there are many domains (e.g., many service providers and large
+ numbers of private networks), multiple layers of brokers MUST be
+ supported for both of the broker models described.
+
+ Integrity or privacy of information between the home and serving
+ domains may be achieved by either hop-by-hop security associations or
+ end-to-end security associations established with the help of the
+ broker infrastructure. A broker may play the role of a proxy between
+ two administrative domains which have security associations with the
+ broker, and relay AAA messages back and forth securely.
+
+
+
+
+
+Glass, et al. Informational [Page 18]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ Alternatively, a broker may also enable the two domains with which it
+ has associations, but the domains themselves do not have a direct
+ association, in establishing a security association, thereby
+ bypassing the broker for carrying the messages between the domains.
+ This may be established by virtue of having the broker relay a shared
+ secret key to both the domains that are trying to establish secure
+ communication and then have the domains use the keys supplied by the
+ broker in setting up a security association.
+
+ Assuming that AAAB accepts responsibility for payment to the serving
+ domain on behalf of the home domain, the serving domain is assured of
+ receiving payments for services offered. However, the redirection
+ broker will usually require a copy of authorization messages from the
+ home domain and accounting messages from the serving domain, in order
+ for the broker to determine if it is willing to accept responsibility
+ for the services being authorized and utilized. If the broker does
+ not accept such responsibility for any reason, then it must be able
+ to terminate service to a mobile node in the serving network. In the
+ event that multiple brokers are involved, in most situations all
+ brokers must be so copied. This may represent an additional burden
+ on foreign agents and AAALs.
+
+ Though this mechanism may reduce latency in the transit of messages
+ between the domains after the broker has completed its involvement,
+ there may be many more messages involved as a result of additional
+ copies of authorization and accounting messages to the brokers
+ involved. There may also be additional latency for initial access to
+ the network, especially when a new security association needs to be
+ created between AAAL and AAAH (for example, from the use of ISAKMP).
+ These delays may become important factors for latency-critical
+ applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Glass, et al. Informational [Page 19]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ Local Domain Home Domain
+ +--------------+ +----------------------+
+ | +------+ | +------+ | +------+ |
+ | | | | | | | | | |
+ | | AAAL +-------+ AAAB +--------+ AAAH | |
+ | | | | | | | | | |
+ | +------+ | +------+ | +------+ |
+ | | | | |
+ | | | +----------------------+
+ +------+ | +---+--+ |
+ | | | | | | C = client
+ | C +- -|- -+ A | | A = attendant
+ | | | | | | AAAL = local authority
+ +------+ | +------+ | AAAH = home authority
+ | | AAAB = broker authority
+ +--------------+
+
+ Figure 6: AAA Servers Using a Broker
+
+ The AAAB in figure 6 is the broker's authority server. The broker
+ acts as a settlement agent, providing security and a central point of
+ contact for many service providers and enterprises.
+
+ The AAAB enables the local and home domains to cooperate without
+ requiring each of the networks to have a direct business or security
+ relationship with all the other networks. Thus, brokers offer the
+ needed scalability for managing trust relationships between otherwise
+ independent network domains. Use of the broker does not preclude
+ managing separate trust relationships between domains, but it does
+ offer an alternative to doing so. Just as with the AAAH and AAAL
+ (see section 5), data specific to Mobile IP control messages MUST NOT
+ be processed by the AAAB. Any credentials or accounting data to be
+ processed by the AAAB must be present in AAA message units, not
+ extracted from Mobile IP protocol extensions.
+
+ The following requirements come mostly from [2], which discusses use
+ of brokers in the particular case of authorization for roaming dial-
+ up users.
+
+ - allowing management of trust with external domains by way of
+ brokered AAA.
+ - accounting reliability. Accounting data that traverses the
+ Internet may suffer substantial packet loss. Since accounting
+ packets may traverse one or more intermediate authorization points
+ (e.g., brokers), retransmission is needed from intermediate points
+ to avoid long end-to-end delays.
+
+
+
+
+
+Glass, et al. Informational [Page 20]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ - End to End security. The Local Domain and Home Domain must be
+ able to verify signatures within the message, even though the
+ message is passed through an intermediate authority server.
+ - Since the AAAH in the home domain MAY be sending sensitive
+ information, such as registration keys, the broker MUST be able to
+ pass encrypted data between the AAA servers.
+
+ The need for End-to-End security results from the following attacks
+ which were identified when brokered operation uses RADIUS [16] (see
+ [2] for more information on the individual attacks):
+
+ + Message editing
+ + Attribute editing
+ + Theft of shared secrets
+ + Theft and modification of accounting data
+ + Replay attacks
+ + Connection hijacking
+ + Fraudulent accounting
+
+ These are serious problems which cannot be allowed to persist in any
+ acceptable AAA protocol and infrastructure.
+
+7. Security Considerations
+
+ This is a requirements document for AAA based on Mobile IP. Because
+ AAA is security driven, most of this document addresses the security
+ considerations AAA MUST make on behalf of Mobile IP. As with any
+ security proposal, adding more entities that interact using security
+ protocols creates new administrative requirements for maintaining the
+ appropriate security associations between the entities. In the case
+ of the AAA services proposed however, these administrative
+ requirements are natural, and already well understood in today's
+ Internet because of experience with dial up network access.
+
+8. IPv6 Considerations
+
+ The main difference between Mobile IP for IPv4 and Mobile IPv6 is
+ that in IPv6 there is no foreign agent. The attendant function,
+ therefore, has to be located elsewhere. Logical repositories for
+ that function are either at the local router, for stateless address
+ autoconfiguration, or else at the nearest DHCPv6 server, for stateful
+ address autoconfiguration. In the latter case, it is possible that
+ there would be a close relationship between the DHCPv6 server and the
+ AAALv6, but we believe that the protocol functions should still be
+ maintained separately.
+
+ The MN-NAI would be equally useful for identifying the mobile node to
+ the AAALv6 as is described in earlier sections of this document.
+
+
+
+Glass, et al. Informational [Page 21]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+9. Acknowledgements
+
+ Thanks to Gopal Dommety and Basavaraj Patil for participating in the
+ Mobile IP subcommittee of the aaa-wg which was charged with
+ formulating the requirements detailed in this document. Thanks to N.
+ Asokan for perceptive comments to the mobile-ip mailing list. Some
+ of the text of this document was taken from a draft co-authored by
+ Pat Calhoun. Patrik Flykt suggested text about allowing AAA home
+ domain functions to be separated from the domain managing the home
+ address of the mobile computer.
+
+ The requirements in section 5.5 and section 3.1 were taken from a
+ draft submitted by members of the TIA's TR45.6 Working Group. We
+ would like to acknowledge the work done by the authors of that draft:
+ Tom Hiller, Pat Walsh, Xing Chen, Mark Munson, Gopal Dommety,
+ Sanjeevan Sivalingham, Byng-Keun Lim, Pete McCann, Brent Hirschman,
+ Serge Manning, Ray Hsu, Hang Koo, Mark Lipford, Pat Calhoun, Eric
+ Jaques, Ed Campbell, and Yingchun Xu.
+
+References
+
+ [1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
+ 2486, January 1999.
+
+ [2] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+ Implementation in Roaming", RFC 2607, June 1999.
+
+ [3] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
+ Protocols", RFC 2477, December 1998.
+
+ 4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [5] Ramon Caceres and Liviu Iftode. Improving the Performance of
+ Reliable Transport Protocols in Mobile Computing Environments.
+ IEEE Journal on Selected Areas in Communications, 13(5):850--
+ 857, June 1995.
+
+ [6] Calhoun, P. and C. Perkins, "Mobile IP Network Address
+ Identifier Extension, RFC 2794, March 2000.
+
+ [7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
+ RFC 2409, November 1998.
+
+ [8] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
+ Public Key Infrastructure Certificate and CRL Profile", RFC
+ 2459, January 1999.
+
+
+
+
+Glass, et al. Informational [Page 22]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ [9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
+ Service (V5)", RFC 1510, September 1993.
+
+ [10] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [11] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
+ Mobile IP", RFC 2356, June 1998.
+
+ [12] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
+ 1996.
+
+ [13] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
+
+ [14] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
+ October 1996.
+
+ [15] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP",
+ Work in Progress.
+
+ [16] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+ Authentication Dial In User Service (RADIUS)", RFC 2138, April
+ 1997.
+
+ [17] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
+ PPP IPCP", RFC 2290, February 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Glass, et al. Informational [Page 23]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+Addresses
+
+ The working group can be contacted via the current chairs:
+
+ Basavaraj Patil
+ Nokia
+ 6000 Connection Drive
+ Irving, TX 75039
+ USA
+
+ Phone: +1 972-894-6709
+ EMail: Basavaraj.Patil@nokia.com
+
+
+ Phil Roberts
+ Motorola
+ 1501 West Shure Drive
+ Arlington Heights, IL 60004
+ USA
+
+ Phone: +1 847-632-3148
+ EMail: QA3445@email.mot.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Glass, et al. Informational [Page 24]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ Questions about this memo can be directed to:
+
+ Pat R. Calhoun
+ Network and Security Center
+ Sun Microsystems Laboratories
+ 15 Network Circle
+ Menlo Park, California 94025
+ USA
+
+ Phone: +1 650-786-7733
+ Fax: +1 650-786-6445
+ EMail: pcalhoun@eng.sun.com
+
+
+ Gopal Dommety
+ IOS Network Protocols
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ USA
+
+ Phone: +1-408-525-1404
+ Fax: +1 408-526-4952
+ EMail: gdommety@cisco.com
+
+
+ Steven M. Glass
+ Sun Microsystems
+ 1 Network Drive
+ Burlington, MA 01803
+ USA
+
+ Phone: +1-781-442-0504
+ EMail: steven.glass@sun.com
+
+
+ Stuart Jacobs
+ Secure Systems Department
+ GTE Laboratories
+ 40 Sylvan Road
+ Waltham, MA 02451-1128
+ USA
+
+ Phone: +1 781-466-3076
+ Fax: +1 781-466-2838
+ EMail: sjacobs@gte.com
+
+
+
+
+
+Glass, et al. Informational [Page 25]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+ Tom Hiller
+ Lucent Technologies
+ Rm 2F-218
+ 263 Shuman Blvd
+ Naperville, IL 60566
+ USA
+
+ Phone: +1 630 979 7673
+ Fax: +1 630 713 3663
+ EMail: tomhiller@lucent.com
+
+
+ Peter J. McCann
+ Lucent Technologies
+ Rm 2Z-305
+ 263 Shuman Blvd
+ Naperville, IL 60566
+ USA
+
+ Phone: +1 630 713 9359
+ Fax: +1 630 713 4982
+ EMail: mccap@lucent.com
+
+
+ Basavaraj Patil
+ Nokia
+ 6000 Connection Drive
+ Irving, TX 75039
+ USA
+
+ Phone: +1 972-894-6709
+ Fax : +1 972-894-5349
+ EMail: Basavaraj.Patil@nokia.com
+
+
+ Charles E. Perkins
+ Communications Systems Lab
+ Nokia Research Center
+ 313 Fairchild Drive
+ Mountain View, California 94043
+ USA
+
+ Phone: +1-650 625-2986
+ Fax: +1 650 625-2502
+ EMail: charliep@iprg.nokia.com
+
+
+
+
+
+
+Glass, et al. Informational [Page 26]
+
+RFC 2977 Mobile IP AAA Requirements October 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Glass, et al. Informational [Page 27]
+