In Chapter 5 we described Mobile IP as one of the most prominent methods for providing mobility for IP network users. We also explained some of the security measures provided for Mobile IP control signaling, such as authentication of Mobile IP transactions between the mobile node and Mobile IP agents and between Mobile IP agents themselves. We described how authentication extensions can be calculated and added to the registration messages to provide integrity protection (authentication) for these messages. However, as mentioned there, calculation of those authentication extensions requires pre-established trust relationships (e.g. security associations including shared secrets) between the mobile node and Mobile IP agents. Unfortunately, Mobile IP base specification [MIP3344] does not provide any details on how these SAs are established. The implication is that, using the base specification alone, if by time of Mobile IP registration the mobile node has not yet established any security associations with its HA or the current FA, it cannot calculate any of those authentication extensions. In this chapter we focus on solving the problem of establishing the security associations required for Mobile IP signaling.
From an administrative point of view, when dealing with large networks serving many roaming mobile nodes, it is not scalable to manually configure security associations between a mobile node and all foreign agents or even between all FAs and HAs beforehand. This may not even be feasible, since the mobile node may not know what HA it is assigned to it at time of booting up. Hence, mechanisms should be provided to set up these security associations dynamically and when required, which is typically the time of Mobile IP registration.
In recent years, many wireless system designers, such as those working in the WLAN 802.11 community, have started using AAA infrastructures for dynamic and real-time generation of security association and distribution of session keys for sessions between end nodes and their network point of attachment. It is safe to assume that the AAA server of the service provider or the enterprise with which the mobile node has been initiated, has access to mobile nodes and its user’s identity and authentication credentials or at least has the functionality to understand and verify this data when necessary. Such a trust relationship allows the AAA server to authenticate the node, its user and its messaging.
The idea here is when a Mobile IP agent receives a registration request from a mobile node, with which it does not have a trust relationship, it can request the AAA server not only to authenticate the MN and its message, but also to generate the necessary keying material to establish trust relationships for the protection of future Mobile IP transactions.
Using the AAA infrastructure brings advantages beyond providing authentication and key management services. Authentication is only part of the security battle; the use of newly acquired IP addresses must be authorized by the network authorities. When the AAA server has access to the user’s service profile, it can make decisions regarding authorization of the user for using network resources as well. Looking at Mobile IP registration process from that angle, we realize that Mobile IP registration request is really an authorization request. Through the registration, the mobile node asks the HA to grant it the right to have two IP addresses and to use the HA resources required for support of traffic routing for those two IP addresses.
Another advantage of using AAA methods is that, while Mobile IP provides the routing mechanisms required for the mobile node’s traffic as the node roams across different networks, the AAA infrastructure can make sure that no business or trust agreements between these networks are violated and the security and integrity of these networks are not threatened as a result of this roaming. Using the AAA infrastructure, the foreign network can simply refer to the client’s home domain to verify its legitimacy, provide the required services, collect the accounting data for the provided services and bill the user’s home domain accordingly, without having to deal with the client directly.
Even though by now we think we have made a good attempt to describe the rationale behind a joint Mobile IP-AAA signaling procedure, we must admit that understanding the IETF specifications for this procedure is a fairly time-consuming and involved task. Part of the specification is defined by the IETF Mobile IP working group, while the other parts of the specification are defined by the AAA community. To make matters worse, on each side only one camp has shown interest in supporting this interaction: On Mobile IP side only Mobile IPv4 has taken the time to define this interaction, and on the AAA side only Diameter is working on providing specification for a Mobile IP application. At the time of writing, Mobile IPv6 has just started producing a statement for the problem [MIP6BOOT] and may or may not adapt a similar process to that for Mobile IPv4. On the AAA side, RADIUS has currently no support for Mobile IP operation, even though some standard bodies, such as 3GPP2 (3rd generation partnership project) have developed vendor-specific RADIUS attributes to provide such support. Continuing with our complaints, we note that even the specifications for required Mobile IP functionality and extensions are spread over multiple Mobile IP documents [MIP3344], [MIPCHAL3012], [3012bis], and [MIPKEYS3957]. Hence we devote an entire chapter to describing what we call Mobile IP-AAA signaling and its variants:
● How Mobile IP registration signaling is extended to outsource the task of mobile node authentication to the AAA servers.
● How Mobile IP registration signaling is extended to request the AAA server to help the mobile node and Mobile IP agents with the generation of security associations and keys for the protection of Mobile IP control signaling.
● How Diameter protocol and servers interact with Mobile IP agents to handle the authenti- cation and key generation requests in a scalable and dynamic fashion.
8.1 Architecture and Trust Model
Mobile IP-AAA signaling is about establishing trust relationships needed for Mobile IP signaling based on relationships provided by the AAA infrastructure. Thus, it is useful to go through the assumed trust model. The trust model includes the architecture elements involved in the signaling and shows what trust relationships exist prior to the start of Mobile IP-AAA signaling and what trust models are generated as a result of this signaling. As one can imagine, the trust model depends on the mobility pattern of the mobile node, the network topology and the administration policies of the networks the model is trying to connect with. It is therefore important to revisit the trust model for every scenario.
Figure 8.1 shows the Mobile IP-AAA signaling trust model for a very generic scenario, where the mobile node attempts to connect with a foreign network that belongs to an administrative domain separate from the administrative domain to which the mobile node and its home network (and HA) belong. The administrative domain for the foreign network is served by a local AAA server (LAAA or AAAL), while the mobile’s home network is served by the so-called home AAA server (HAAA or AAAH). In the model shown in Figure 8.1, the foreign network deploys a foreign agent (FA) to assist the visiting mobile nodes with CoA acquisitions and Mobile IP signaling. Note that FA is a Mobile IPv4-only concept that does not exist for Mobile IPv6. Furthermore, even some networks implementing Mobile IPv4 may not deploy FAs, which means the mobile node must use a co-located care of address (CcoA) and register directly with the HA. In such cases the model may be significantly simpler. Another simpler case is when the FA belongs to the same administrative domain as the HA and hence is served by the HAAA. On the other hand, to keep the description of the protocols from becoming too complicated, we assume that the two networks have compatible administration and security policies. Also for this discussion we do not get into how routing of AAA messages between two different administra- tion domains takes place in general. We simply assume that the local AAA server in the foreign network has a way of determining how to contact the home AAA server for the mobile node. Figure 8.1 shows a variety of security associations (SAs). Before going into the description of each sort, we would like to point out that in this discussion security association does not necessarily refer to IPsec security associations. By SA, we simply mean a security context that exists between the two entities and defines the keys, transforms, and algorithms that are used to perform the security functions related to the Mobile IP-AAA signaling procedure.
MN Local AAA server FA Home AAA server HA AAASA MSA MSA PSA PSA PSA MSA