AAA-Based Dynamic Key Generation

The Cisco Dynamic security association and Key Distribution feature has been covered extensively, but it is not currently a standards-based solution. Chapter 3, "Mobile IP Security," mentioned that work on a standard AAA-based dynamic key-generation mechanism is under way. At the time of this writing, this work was still under way, so we are presenting a preview of the yet-to-be-accepted standard.

Mobile IPv4 provides the following extensions to protect control messages between the entities:

• Mobile Node Home Agent Authentication Extension

• Mobile Node FA Authentication Extension

• FA Home Agent Authentication Extension

• Mobile Node AAA Authentication Extension

These extensions provide authentication for Registration Requests (RRQs) and Registration Replies (RRPs) between the Mobile Node and Home Agent, Mobile Node and FA, FA and Home Agent, and Mobile Node and AAA server, respectively. Of these, only the Mobile NodeHome Agent Authentication Extension is mandatory. Authentication between the Mobile Node and FA and between the FA and Home Agent is optional. The Mobile NodeAAA Authentication Extension is required in an environment where a AAA server authenticates the Mobile Node.

The Mobile Node and Home Agent security assocation (security association) is typically based on a static preshared key, which is configured on both the Mobile Node and Home Agent. Another variant is a configuration of the key on the AAA server for the Home Agent to download before authenticating the Mobile Node. As pointed out in Chapter 3, configuring the Mobile Node can be a deployment hurdle. Having to set up another key for a client solely for Mobile IP is hard to justify for an IT department. The Zero Configuration Client (ZeCC) approach leverages the existing enterprise security infrastructure to dynamically generate the key for a Mobile IP session. However, because not all deployments use such a security infrastructure, a generic mechanism for dynamic key generation is warranted.

The generalized scheme fundamentally differs from ZeCC by specifying a new operation on the AAA server. New attributes are also needed in the RADIUS or Diameter protocol between the FA and Home Agent and the AAA server. The mobility entities communicate the authentication and key derivation method requested by the Mobile Node to the AAA server, which sends the key and keying material (targeted for the Mobile Node) to the FA and Home Agent.

The proposed IETF AAA-based key-generation mechanism creates new extensions in the RRQ and RRP messages to carry the keying material and security association parameters. In the RRQ, extensions exist to request a key between the Mobile Node and FA and/or a key between the Mobile Node and Home Agent. The extension also specifies the mechanism of how the key should be generated on the Mobile Node and AAA server. The Mobile Node adds the extension(s) in the RRQ to obtain the required key to authenticate with the mobility entities, which communicate with the AAA server using the RADIUS or Diameter protocol. At this time, the messaging has not been defined. The AAA server recognizes that key-generation request and offers the key in the reply to the FA and/or Home Agent. Also, the reply contains the key-generation material for the Mobile Node. The FA and Home Agent transfer the AAA information to extensions in the Registration Reply (RRP). Upon receiving the RRP, the Mobile Node obtains the information to generate the key to authenticate registration exchanges with the FA and Home Agent.

The new extensions are protected by the Mobile NodeAAA Server Authentication Extension in the RRQs and the Mobile NodeFA or Mobile NodeHome Agent Authentication Extension in the RRPs. The keys that authenticate the RRP are derived from the embedded keying material.

To secure its signaling, Mobile IP needs to leverage the existing security infrastructure, which is typically AAA based. Having a key-generation capability that uses an existing authentication mechanism simplifies deployment.