Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
Extracted elements (31)
A single AAA Security Association is reused to create derivative Mobility Security Associations rather than pre-configuring MN-FA and MN-HA keys, enabling mobile nodes that lack any pre-existing Mobility Security Association (e.g., because they have no home address yet) to bootstrap securely via the AAA infrastructure.
The key derivation uses HMAC-SHA1(AAA-key, nonce || MN-identifier) rather than transmitting the key directly; this allows the Registration Reply to carry only the nonce, which does not expose the AAA key even if the reply is observed by an adversary.
Transform identifiers for Mobility Security Associations reuse the IPsec 'Authentication Algorithm' attribute table to maintain algorithm independence and avoid defining a parallel identifier space for Mobile IP.
The extensions are designed to work with any AAA protocol suite (not just RADIUS or Diameter) that satisfies RFC 2977 requirements, as long as the AAA infrastructure can securely distribute key material to mobility agents out-of-band.
All mobile nodes and mobility agents implementing these extensions MUST implement HMAC-SHA1; other message authentication codes or keyed hash functions MAY also be used as configured in the AAA Security Association.
Any registration reply containing the MN-HA Key Generation Nonce From AAA extension MUST also contain a subsequent Mobile Home Authentication extension created using the generated MN-HA key; similarly, a reply with the MN-FA extension MUST contain a subsequent Mobile Foreign Authentication extension.
If a MN-HA Key Generation Nonce Request was present in the Registration Request but no MN-HA Key Generation Nonce Reply extension is present in the Registration Reply, the mobile node MUST discard the Registration Reply.
If one or more AAA Key Generation Nonce Request extensions were added to the Registration Request, the mobile node MUST add the MN-AAA Authentication extension to that Registration Request.
If the Mobile-Home Authentication check on the Registration Reply fails using the newly derived MN-HA key, the MN MUST discard the Registration Reply and the new Mobility Security Association, reverting to the old one if any.
If the mobile node does not have a Mobility Security Association with the home agent, it MUST add an MN-HA Key Generation Nonce Request extension as part of its Registration Request sent to the Foreign Agent.
The AAA Security Association between the mobile node and the AAA server MUST be refreshed periodically to deny adversaries unbounded time to break its secrecy.
The AAA server MUST generate a random Key Generation Nonce of at least 128 bits, and this same minimum length applies to the Key Generation Nonce field in both MN-FA and MN-HA reply extensions.
The MN-FA AAA KeyGen Reply extension MUST appear in the Registration Reply before the Mobile-Foreign Authentication extension; the MN-HA AAA KeyGen Reply extension MUST appear before the MN-HA Authentication extension.
The MN-FA AAA KeyGen Request (subtype 1) and MN-HA AAA KeyGen Request (subtype 1) MUST each appear in the Registration Request before the MN-AAA Authentication extension.
When unsolicited key material is provided by the AAA server, the mobile node MUST calculate new keys and update or create its relevant Mobility Security Association.
A Mobility Security Association is a simplex connection that applies security services to MIPv4 control traffic between a MN and HA (or MN and FA), uniquely identified by the peer source and destination IP addresses and an SPI.
Key derivation at the mobile node computes: key = HMAC-SHA1(AAA-key, Key Generation Nonce || mobile node identifier), where the identifier is the NAI if present in the Registration Request, otherwise the Home Address.
The MN-FA Key Generation Nonce Reply Extension (Type 41) is included in a Registration Reply to supply the mobile node with keying material for establishing a Mobility Security Association with the foreign agent; its subtype data format depends on the subtype.
The MN-FA Key Generation Nonce Request Extension (Type 40) is included by the mobile node in a Registration Request to request that the AAA infrastructure create a registration key for use with the foreign agent; it carries a Mobile Node SPI and variable subtype data.
The MN-HA Key Generation Nonce Reply Extension (Type 43) supplies the mobile node with a Key Generation Nonce and associated parameters for deriving the MN-HA key and creating a Mobility Security Association with the home agent.
The MN-HA Key Generation Nonce Request Extension (Type 42) is included by the mobile node in a Registration Request to request an MN-HA key from the AAA infrastructure; it carries a Mobile Node SPI and variable subtype data.
IANA assigned error code MISSING_MN_FA (value 107) for use in a Registration Reply Code field when no MN-FA Key Generation Nonce Reply extension is present and the foreign agent has no existing Mobility Security Association with the mobile node.
IANA assigned four new non-skippable Mobile IP extension type codes: MN-FA-KeyGen Request (40), MN-FA-KeyGen Reply (41), MN-HA-KeyGen Request (42), MN-HA-KeyGen Reply (43), taken from the numbering space of RFC 3344 as extended by RFC 2356.
IANA created a registry for KeyGen Request/Reply subtypes; initial entry is subtype 1 ('from AAA'). New subtypes require Standards Action.
IANA created a Replay Method Identifier namespace; values 2 (Timestamps) and 3 (Nonces) are defined by RFC 3344, 0 and 1 are reserved, and all others are available pending Designated Expert review.
The Mobility Security Associations derived from these extensions offer no higher security than the underlying AAA Security Association between the mobile node and the AAAH; the AAA SA must therefore be refreshed periodically to limit adversary attack windows.
The Reply extensions carry only Key Generation Nonces used to derive keys, not the AAA key itself; thus they do not expose data that could be used in an attack aimed at recovering the shared MN-AAA secret.
The Generalized MN-FA and MN-HA KeyGen Request extensions share a common header: Type (8-bit), Subtype (8-bit), Length (16-bit), Mobile Node SPI (32-bit), followed by variable subtype data; Length equals subtype data bytes plus 4.
The Generalized MN-HA KeyGen Reply extension header is: Type (8-bit), Subtype (8-bit), Length (16-bit), Lifetime (32-bit), followed by variable subtype data; Length equals subtype data bytes plus 4 for the Lifetime field.
The MN-FA Key Generation Nonce From AAA subtype-specific data (subtype 1) contains: Lifetime (32-bit, seconds), AAA SPI (32-bit), FA SPI (32-bit), Algorithm Identifier (16-bit), and Key Generation Nonce (variable, at least 128 bits).
The MN-HA Key Generation Nonce From AAA subtype-specific data (subtype 1) contains: AAA SPI (32-bit), HA SPI (32-bit), Algorithm Identifier (16-bit), Replay Method (16-bit), and Key Generation Nonce (variable, at least 128 bits).