Dynamic Keying

The complexity of managing static preshared keys can be a daunting task, especially for larger enterprises. Deploying a client-based Mobile IP solution would be cost prohibitive if each Mobile Node needed to be manually configured with one or more keys. Couple this with the fact that any static security key is usually reissued (rekeyed) periodically to prevent rogue nodes from capturing a key and using it indefinitely. Even if you consider a network with 100 Mobile Nodes, each having 2 keys, that would result in 200 keys that an administrator would need to manually configure. By the time she finished configuring all the keys, it might be time to reissue each of those keys!

Instead, wouldn't it be nice if the mandatory Mobile Node-Home Agent key could be generated dynamically? Or, even if a preshared key existed, wouldn't it be nice if session keys could be dynamically generated so that the Mobile Node and Home Agent wouldn't need to be rekeyed periodically. That is, a security key (session key) could be generated dynamically for each Mobile IP session from a static key. Because the session key would be valid only for that session, in a sense it is being rekeyed for each session.

Dynamic keying reduces the need to provision new keys on the Mobile Node and Home Agent also protects against rogue nodes that are trying to crack the key. Remember, when it comes to cryptography, it is not a matter of if the encryption can be broken but when. The goal is to make the cracking so difficult that the data is irrelevant by the time the encryption can be broken. For example, if someone can capture your encrypted sales figures, but it takes him 1000 years to read them, is that data relevant? To make the capturing of the encrypted data even more difficult, imagine that the sales report is split into five pieceseach encrypted using a different key. Then it would take five times as long to read it! It is more difficult to break the code if you have less data and you have an effective cryptography system. The same premise is used for dynamic keying systems in Mobile IP.

Standards-Based Dynamic Keying

An IETF draft, "AAA Registration Keys for Mobile IPv4," authored by Perkins and Calhoun, is nearing standardization to provide a replacement for the static preshared keys used in Mobile IP authentication. This draft, while attempting to be AAA-server agnostic, does not appear to be usable with a RADIUS server and is definitely not usable with existing AAA servers. The draft is designed to use the advanced features of a Diameter server. (Diameter is designed to be a replacement for RADIUS.) Diameter has not been widely adopted, and as such, this draft did not seem like the ideal way to simplify enterprise deployment. In fact, without a larger Diameter deployment base, this draft, though perhaps useful, will be limited in the places it can be used.

Cisco Dynamic Security Association and Key Distribution

The Cisco Dynamic security association and Key Distribution feature was designed to derive dynamic session keys on the Mobile Node and Home Agent. It integrates with common enterprise infrastructure as part of the Zero Configuration Client, or ZeCC, solution. ZeCC, covered more in Chapter 5, in turn is designed to integrate with existing services, including Dynamic Host Configuration Protocol (DHCP), RADIUS, and Windows domain controllers.

Cisco Dynamic security association and Key Distribution uses vendor-specific extensions to the RRQ and reply messages to derive session keys on both peers. The basic message flow is shown in Figure 3-7. RFC 2759, "Microsoft PPP CHome AgentP extensions version 2 (MS CHAPv2)," is used with Windows login credentials obtained at the Mobile Node to authenticate the initial RRQ. A hash of the hashed user password along with data from the initial RRQ generate a permanent key from which transient session keys are generated. Either the permanent key or transient session keys can then perform Mobile NodeHome Agent authentication. To accomplish this key establishment, five vendor-specific extensions can be used, and four other extensions are defined to carry configuration information.

Figure 3-7. Cisco Dynamic Security Association and Key Distribution Call Flow

Session Index Extension

The session index differentiates between multiple devices being operated by the same user. For example, if a user has a laptop and a personal digital assistant (PDA) both running Mobile IP and using the same Windows login credentials, separate keying sessions must be maintained for each device.

The session index is a textual name, usually the host name or network ID of the Mobile Node. The session index is combined with the network access identifier (NAI) to form a session identifier. The session identifier is similar to the IP Address/SPI pair that identifies the Mobile Node's security association. A typical session identifier would be user.pda or user.laptop. The use of a session index extension is optional.

Security Association Setup Extension

MHAE requires more than just a key to be completed. A security context, identified by an SPI value, must also contain the authentication algorithm and the replay protection method. The security association setup extension allows the Mobile Node to inform the Home Agent how to build a complete security association. The Mobile Node selects a random unused value between 256 and 65,535 for use as an SPI, and the node identifies the authentication algorithm, replay protection method, and key it will use. The Mobile Node can send one security association setup extension for the permanent key and can send another for the transient key. If, after the first registration, the Mobile Node or Home Agent desires a new transient session key, it computes the new key and includes an security association setup extension with the new SPI, algorithm, and replay protection. Either the Home Agent or Mobile Node can rekey at any time.

Domain Extension

Microsoft Windows authentication allows users to be associated with a domain. The domain is similar to the realm portion of the NAI. If multiple domains are in use within an enterprise, the domain extension must carry the domain name of the user. This allows the AAA server to route the query to the proper domain controller for authentication. This extension is optional.

Challenge Extension

MS CHAPv2 requires the use of a challenge value similar to that in FA CHAP, as described in the section "FA Challenge," earlier in this chapter. This value can be a random number chosen by the Mobile Node. The recommended CHAP value is a 16-byte concatenation of the Home Agent address, the Care-of Address (CoA), and the identification field. Having the Mobile Node generate its own challenge defeats the purpose, but because the replay protection defined in the Mobile Node-Home Agent security association already protects against replay attacks, the challenge is not necessary. The challenge essentially maintains compatibility with the existing protocol so that infrastructure does not need to be updated. The challenge extension is mandatory.

Authentication Response Extension

The authentication response extension carries the authenticator value computed over the RRQ using MS CHAPv2 and a hash of the user password. This provides the bootstrap authentication that authenticates the initial RRQ from which the dynamic Mobile Node-Home Agent keys can be derived. This extension is mandatory but is only used in the initial RRQ. After the session keys have been derived, they are used in the MHAE to authenticate registration update messages.

Configuration Extensions

While not related to the derivation or distribution of security associations, four more extensions are defined as part of Cisco Dynamic security association and Key Distribution to facilitate the zero-configuration client solution. These extensions are as follows:

• The Home network prefix extension allows the Home Agent to inform the Mobile Node of the prefix or netmask that should be used with the assigned home address.

• The Domain Name System (DNS) server extensions provide the Mobile Node with DNS servers it should use during the session.

• The DHCP server extension and the DHCP client identifier extension are optional parameters that allow the Mobile Node to acquire configuration options from and maintain a lease with the DHCP.

Location Privacy

Beyond the basic concepts of authentication and authorization, location privacy often comes up in Mobile IPSec discussions. The concern is that the Mobile IP registration process divulges too much information about the location, both physically and logically, of a Mobile Node, its home network, and as such, the person to whom the Mobile Node belongs. For example, if a delivery company has Mobile Nodes in each vehicle, it could easily determine whether a driver had left his route and gone home for lunch by evaluating the physical location of the CoA used by the Mobile Node. The Mobile Node might also not want the foreign network to know where the node is from.

However, the privacy implications in Mobile IP v4 are debatable. Because no support exists for route optimization, only the operator of the Home Agent has direct access to the CoA information. It is clearly possible to use a location-discovery mechanism like traceroute to discover the location of a Mobile Node, but this can be blocked. While location privacy should be considered when evaluating the security impacts of a Mobile IP solution, these impacts are rarely formidable enough to preclude deployment.