The Mobile IP and Authentication, Authorization, and Accounting (AAA) working groups in IETF have been looking at defining the requirements for AAA. RFC 2977  contains the requirements that would have to be supported by an AAA service to aid in providing Mobile IP services.
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 that 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 chapter. Once authenticated, the mobile
Mobile IP is a technology that enables a network node (a 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 that 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-
In RFC 2977, an attempt is made to exhibit the requirements in a progressive fashion. After showing the basic AAA model for Mobile IP, it lists the model's requirements as
It must be based on the general model.
It must be based on providing IP service for mobile nodes.
It must be derived from specific Mobile IP protocol needs.
RFC 2977 frequently uses the following terms in addition to those defined in RFC 2002: [38,39,40,41]
Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation.
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.
The act of verifying a claimed identity in the form of a
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, that is 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.
Interdomain accounting Interdomain accounting is the collection of information on the resource usage of an entity within an administrative domain, for use within another administrative domain. In interdomain accounting, accounting packets and session records will typically cross administrative boundaries.
Intradomain accounting Intradomain accounting is the collection of information on resources within an administrative domain, for use within that domain. In intradomain 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 This represents a summary of the resource consumption of a user over an entire session. Accounting gateways creating the session record may do so by processing interim accounting events.
This section covers the main features of a basic model for the operation of AAA servers that have good support within the Mobile IP working
Figure 4-16: 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
The local authority (AAA Local [AAAL]) itself may not have enough information stored locally to carry out the verification of the client's credentials. In contrast to the attendant, the AAAL is 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
Once the local authority has obtained authorization and notified the attendant about the successful negotiation, the attendant can provide the requested resources to the client. There may be many attendants for each AAAL in the picture, and there might be many clients from many different home domains. Each home domain provides an AAAH that can check credentials originating from clients administered by that home domain.
An implicit security model is shown in Figure 4-16, and identifying the specific security associations it assumes is quite important. First, it is natural to assume that the client has a security association with the AAAH, since that is
Finally, the figure clearly shows 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 from today's Internet, one can cite the deployment of RADIUS  as an instance in which mobile computer clients 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 his or her credentials (identification, unique data, and an unforgettable 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 previous description and example, several requirements fall out:
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.
The attendant has to keep state (retain information) for pending client requests while the local authority contacts the appropriate external authority. Since the mobile node may not
It is easy to 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
Figure 4-17: Security associations
In addition to the requirements listed, one specifies the following requirements that derive from operational experience with today's roaming protocols:
An attendant will have to manage requests for many clients at the same time.
The attendant must protect against replay attacks.
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 QoS 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
Lastly, recent discussion on the Mobile IP working group indicates that the attendant must be able to terminate service to the client based on policy determination by either the AAAH or AAAL server.
This section details additional requirements based on issues
A reliable AAA transport mechanism must be supported:
There must be an effective
This transport mechanism must be able to
Retransmission is controlled by the reliable AAA transport mechanism, and not by lower-layer protocols such as TCP.
Even if the AAA message is to be forwarded, or the message's options or semantics do not conform to the AAA protocol, the transport mechanism will
Acknowledgements may be piggybacked in AAA messages.
AAA responses have to be delivered in a
A digital certificate in an AAA message must be transported in order to minimize the number of round trips associated with AAA transactions. Note that this requirement applies to AAA applications and not mobile
Message integrity and identity authentication on a hop-by-hop (AAA node) basis must be provided.
Replay protection and optional nonrepudiation capabilities for all authorization and accounting messages must be supported. The AAA protocol must provide the capability for accounting messages to be matched with prior authorization messages.
Accounting must be supported via both bilateral arrangements and broker AAA servers providing accounting clearinghouse services 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
The requirements listed in the previous section pertain to the relationships between the functional units and do not 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.
The RFC places the following additional requirements on the AAA services in order to satisfy such clients:
Any 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.
AAA servers must be able to identify the client by some means other than its IP address.
Policy in the home domain may
AAA servers today identify clients by using the Network Access Identifier (NAI).  A mobile node can identify itself by including the NAI along with the Mobile IP registration request.  The NAI is of the form 'user@realm.' It is unique and well suited for use in the AAA model illustrated in Figure 4-16. Using a NAI such as user@realm allows AAAL to easily determine the home domain ('realm') for the client. Both the AAAL and the AAAH can use the NAI to keep records indexed by the client's specific identity.
Clients using Mobile IP require specific features from the AAA services in addition to the requirements already mentioned for basic AAA functionality and IP connectivity. To understand the application of the general model for Mobile IP, consider the mobile node to be the client in Figure 4-16, and the attendant to be the foreign agent. If a situation arises that no foreign agent is present (as 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, such as a DHCP server, for instance. Such attendant functionality is outside the scope of this chapter.
The home agent, while important to Mobile IP, is allowed to play a role during the initial registration that is subordinate to the role
Figure 4-18: AAA Servers with Mobile IP Agents
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 communication 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 the integration of the AAA functions
As attendants may provide many different types of subservices to mobile clients, there must be extensible accounting formats. In this way, the specific services being provided can be identified, including accounting support, should more services be identified in the future.
The AAA home domain and the home agent home domain of the mobile node need not be part of the same administrative domain. Such a situation can occur if the home address of the mobile node is provided by one domain, such as an ISP that the mobile user uses while at home, and the authorization and accounting by another (specialized) domain, such as a credit card company. The foreign agent sends only the authentication information of the mobile node to the AAAL, which interfaces with 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 [38,39,40,41] without further interaction with the AAA.
Whether to combine or separate the Mobile IP protocol data with or 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 of the needed AAA and Mobile IP functions should be
For Mobile IP, the AAAL and the AAAH servers have the following additional general
Enable (re)authentication for Mobile IP registration.
Authorize the mobile node (once its identity has been established) to use at least the set of resources for minimal Mobile IP functionality, plus
Initiate accounting for service utilization.
Use AAA protocol extensions
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 4-16 because the tasks often happen together, and task processing needs access to the same data at the same time.
In the model in Figure 4-16, the initial AAA transactions are handled without needing the home agent, but Mobile IP requires every registration to be handled between the home agent and the foreign agent, as shown by the sparse dashed (lower) line between them in the figure. 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 4-18 would not be needed, and subsequent Mobile IP registrations would only follow the lower control
Any Mobile IP data that is sent by the foreign agent through the AAAL to AAAH must be
As we have discussed, 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 can be provided via several different algorithms. Some algorithms rely on the existence of a public-key infrastructure (Housley, Ford, Polk, and Solo); others rely on the distribution of symmetric keys to the communicating nodes (Kohl and Neuman). 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 in order to provide the following security functions:
Identify or create a security association between the mobile node and the home agent; this is required for the mobile node to produce the(re)authentication data for the mobile node/home agent authentication extension, which is mandatory on Mobile IP registrations.
Identify or create a security association between the 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
Identify or create a security association between the 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.
Validate certificates provided by the mobile node and provide reliable indication to the foreign agent.
Accept on the part of AAAL 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. The lifetime for those security associations should be an integer multiple of the registration lifetime
Conditionally accept a Mobile IP registration authorization according to 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 tunneling support to the home domain through the foreign agent.
The lifetimes of any security associations distributed by the AAA server for use with Mobile IP should be great enough to avoid a too frequent initiation of the AAA key distribution, since each invocation of this process is likely to cause lengthy delays between (re)registrations.  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). 
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.
Mobile IP with Dynamic IP Addresses 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 for the one between themselves and the AAAH (see Figure 4-17). 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 the 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 with a home agent that might be designated by the mobile node.
Allocating a home address and a home agent for the mobile further
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 the existing industry practice for the way NAIs are used today. 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. The section entitled 'Broker Model' suggests a way to reduce the number of security associations that have to be
Firewalls and AAA
Mobile IP has
Mobile IP with Local Home Agents
In some Mobile IP models, mobile nodes boot on subnets that 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, it can use Mobile IP to roam around that domain, calling the subnet on which it
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 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 reduce delays for new Mobile IP registrations.
In Figure 4-19, 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 figure, it is evident that such a configuration avoids problems with firewall protection at the domain boundaries. 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
Figure 4-19: Home agent allocated by AAAL
Mobile IP with Local Payments Since the AAAL will be able to allocate a local home agent upon demand, one can make a further simplification. In cases where the AAAL can manage any necessary authorization function locally (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 4-20.
Figure 4-20: Local payment for local Mobile IP services
In this simplified model, one may consider that the role of the AAAH is taken over either by a national government (in the case of a cash payment), by a card authorization service if payment is by credit card, or some 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 areas where business clients are likely to
Since movement from coverage area to coverage area may be frequent in Mobile IP networks, it is imperative that the latency involved in the
The new foreign agent can use this information to either contact the previous foreign agent to retrieve the Key Distribution Center (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 the new keying information. After initial authorization, further authorizations should be done locally within the local domain.
When a mobile node moves into a new foreign subnet as a result of a handover and is now
Figure 4-1 displays a configuration in which the local and the home authority have to share a 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)
The integrity or privacy of information between the home and serving domains may be achieved by either hop-by-hop security associations or endto-end security associations established with the help of the broker infrastructure. A broker may play the role of a proxy between two administrative domains that have security associations with the broker and that relay AAA messages back and forth securely.
Alternatively, a broker may also enable the two domains with which it has associations, but the domains themselves do not have a direct association when 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 having the domains use the keys supplied by the broker in setting up a security association.
Assuming that an AAA broker (AAAB) accepts responsibility for payment to the serving domain on
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,
The AAAB in Figure 4-21 is the broker's authority server. The broker acts as a
Figure 4-21: AAA servers using a broker
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, 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 Aboba and Vollbrecht  , who discuss the use of brokers in the particular case of authorization for roaming dial-up users:
The management of trust with external domains by way of
Accounting reliability-accounting data that traverses the Internet may suffer substantial packet loss. Since accounting packets may traverse one or more intermediate authorization points (brokers), retransmission is needed from intermediate points to avoid long end-to-end delays.
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 that were identified when brokered operations use RADIUS (see Figure 4-17 for more information on the individual attacks):
Theft of shared secrets
Theft and modification of accounting data
These are serious problems that no acceptable AAA protocol or infrastructure can permit to persist.
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 on today's Internet because of experience with dial-up network access.
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 at the
 S. Glass, T. Hiller, S. Jacobs, and C. Perkins, 'RFC 2977, Mobile IP Authentication, Authorization, and Accounting Requirements.' October 2000.
 The rest of this section is based on S. Glass, T. Hiller, S. Jacobs, and C. Perkins. 'RFC 2977, Mobile IP Authentication, Authorization, and Accounting Requirements.' October 2000.
[38,39,40,41] C. Perkins, 'RFC 2003: IP Encapsulation within IP.' October 1996.
[38,39,40,41] C. Perkins, 'RFC 2003: IP Encapsulation within IP.' October 1996.
 ---. ' RFC 2002: IP Mobility Support.' October 1996.
 ---. 'RFC 2004: Minimal Encapsulation within IP.' October 1996.
 J. Solomon and S. Glass, 'RFC 2290: Mobile-IPv4 Configuration Option for PPP IPCP.' February 1998.
[38,39,40,41] C. Perkins, 'RFC 2003: IP Encapsulation within IP.' October 1996.
[38,39,40,41] C. Perkins, 'RFC 2003: IP Encapsulation within IP.' October 1996.
 C. Rigney, A. Rubens, W. Simpson, and S. Willens, 'RFC 2138: Remote Authentication Dial In User Service (RADIUS).' April 1997.
 B. Aboba and M. Beadles, 'RFC 2486: The Network Access Identifier.' January 1999.
 P. Calhoun and C. Perkins, 'RFC 2794: Mobile IP Network Address Identifier Extension.' March 2000.
 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.
 D. Harkins and D. Carrel, 'RFC 2409: The Internet Key Exchange(IKE).' November 1998.
 G. Montenegro and V. Gupta, 'RFC 2356: Sun's SKIP Firewall Traversal for Mobile IP.' June 1998.
P. Mockapetris, 'STD 13, RFC 1035: Domain
 C. Perkins and D. Johnson, 'Route Optimization in Mobile IP.' Work in progress.