Summary

  • RFC 5269 separates a CGA/SEND signing key, a dedicated handover-key encryption pair and a shared handover key. The first proves authority to claim the provisioning source address, the second transports the secret, and the third authenticates an FBU.
  • A valid FBU MAC authorizes a forwarding change for one previous care-of CGA at one previous router. It does not authenticate device location, the new care-of address, packet delivery, a user, an application or a permanent Mobile IPv6 binding.

A powerful proof became dangerous only when its label grew

The attack RFC 5269 addresses is concrete. A Fast Binding Update can make the previous access router redirect traffic sent to a mobile node's former care-of address. If any nearby sender can issue that instruction, an attacker can move a victim's traffic elsewhere.

The remedy is a shared handover key. The mobile node and access router establish it before the handover. Later, the mobile node computes an authorization MAC over the FBU. The previous router finds the matching key and verifies the authenticator before it changes forwarding.

That is a meaningful cryptographic control. The error begins when a management layer records its output as “handover authenticated.” The MAC did not observe a radio association. It did not run Duplicate Address Detection for the proposed new address. It did not see the new router release a buffer or the mobile node receive data. It authorized one signaling operation concerning an old address.

Purpose is not a footnote to a key. Purpose is the boundary that makes the proof interpretable.

Three keys exist because three claims are different

RFC 5269 deliberately avoids one universal credential.

First comes the CGA/SEND key pair. The mobile node's care-of address is a Cryptographically Generated Address. Its RtSolPr provisioning request carries the CGA parameters and a SEND signature. Successful SEND validation lets the access router determine that the sender is authorized to claim that source CGA.

Second, the mobile node creates a separate public/private pair for handover-key encryption. It uses the same public-key algorithm and parameters as SEND, but the specification is explicit that this pair is independent. It must not be used for any other encryption or for signatures. The public half travels in the Handover Key Request Option; the private half remains with the mobile node and decrypts the reply.

Third, the access router creates or retrieves the shared handover key. It encrypts that key to the dedicated public key and returns it in the Handover Key Reply Option. The shared key is later used to compute the FBU authenticator.

Collapsing these objects into a field called mobilityKey destroys the model. The SEND private key signs an address-claiming exchange. The transport private key unwraps a secret. The shared secret authenticates one class of message. They have different creation authorities, permitted uses, rotation triggers and exposure consequences.

Provisioning starts only after SEND succeeds

The mobile node asks for a key by sending RtSolPr from its care-of CGA. The request includes the handover-key encryption public key, a preferred FBU authentication Algorithm Type, the SEND CGA and Signature options, and a SEND Nonce.

The access router must validate the request under SEND first. If validation fails, it must not include a Handover Key Reply Option, must not provision a key and must not alter an existing record for that address. The last rule matters: a forged request must not be allowed to destroy the legitimate mobile node's cached authorization state.

The order is also a capacity control. Creating a random shared key and reserving cache state costs resources. RFC 5269 says the router should not generate that state before it has verified the originator. Rate limiting RtSolPr, restricting unresolved state and careful cache management remain necessary because authentication does not make requests free.

A production trace therefore needs both results: SEND validation and admission. “Signature valid” does not prove that state was safely allocated; “key returned” does not reveal whether validation preceded allocation.

The reply needs more than successful decryption

For a validated request, the router either returns the key already associated with the CGA or creates a new one. It encrypts the shared key with the public key carried in the request. The PrRtAdv reply also carries the key lifetime, selected Algorithm Type and the original SEND nonce.

The router side of the exchange has its own identity requirement. The access router must have a certificate suitable for a SEND-capable router, support certificate discovery and sign the reply. The mobile node must verify that the signing key is the router's certified public key. If the certification path is not cached, SEND CPS/CPA messages provide the discovery path. An uncertified reply is dropped.

The nonce links the reply to the request and selects the correct handover-key decryption pair when the mobile node has more than one. A reply with no matching nonce is dropped. Only then does the node use the matching private key to decrypt the shared secret.

This yields a receipt chain, not a single “decrypt OK” event: request generation, CGA claim, SEND signature, router validation, certificate path, router signature, echoed nonce, algorithm selection, matching private key and key lifetime. If an audit preserves only the final secret identifier, it cannot show which router, request or policy produced it.

The cache key is a relationship

On the router, the shared handover key is indexed by the mobile node's CGA, with the selected authentication algorithm and lifetime. On the mobile node, key selection for a later FBU uses the previous router's identity and the mobile node's previous care-of CGA on that link.

The FBU carries the old care-of CGA in its Home Address Option. The previous access router uses that address to find the key. If no matching key exists, it must not change forwarding.

This is relational authority. The same device may visit several routers. One router may answer several requests. A mobile node may retain keys from multiple responders. A CGA may reappear when the node returns. Key bytes alone do not name the authority; the router, mobile address, algorithm, generation and lifetime do.

A cache keyed only by “device ID” or “current router” can select the wrong proof while still producing a valid MAC under some key. Cryptographic success cannot correct a mistaken database join.

Algorithm choice belongs in the evidence

The request includes the mobile node's preferred FBU authentication algorithm. The router should return that choice if supported; otherwise it must select an algorithm of equivalent or greater strength. The mobile node uses the returned Algorithm Type.

When several routers respond, the node may keep several keys. If none offers a supported algorithm, it may retry. But it should not answer a compromised router's bidding-down pressure by requesting something weaker than the original preference.

An audit record that says only “MAC valid” omits the policy that determined what “valid” meant. The Algorithm Type, requested preference, returned choice and policy generation should travel with the result. A later policy change must not silently reinterpret an old authenticator.

Unexpired is not the same as renewed

RFC 5269 gives separate default reuse limits. The handover-key encryption public pair has a suggested maximum of 12 hours or ten handovers, whichever comes first. The shared handover key has a default lifetime of 12 hours, or 43,200 seconds.

The access router generates a random shared key of sufficient strength for the authentication algorithm, unique for each CGA public key. Key generation should be uncorrelated across handover keys and between handover and CGA keys.

The previous router may keep a still-valid shared key because the mobile node can move again before ordinary Mobile IPv6 binding finishes. If the node later returns with the same care-of CGA, the router may send the same key again. But the node must not assume that remembered bytes remain authorized. It has to receive the key again from the router.

That sentence is an operational gift. Local possession, local timer validity, router retention and fresh reprovisioning are four different states. “Cached” must never mean “renewed.” The mobile node should discard the key after normal MIPv6 binding completes at the new router; the previous router must discard it when forwarding times out or the key lifetime ends.

A purpose-built key should stay purpose-built

RFC 5269 describes the shared secret as an example of purpose-built key architecture. That is not branding. It is an instruction against authority creep.

The shared key authenticates changes associated with handover for the former address at the previous router. It does not encrypt tunneled user packets. It is not an application session key. It does not authenticate a subscriber or employee. It does not validate the prospective NCoA, replace ordinary Mobile IPv6 Binding Update or Return Routability, or prove that a correspondent node accepted a binding.

The current FMIPv6 base specification is RFC 5568, which obsoleted RFC 5268 and continues to refer to RFC 5269 for establishment of the shared handover key used by the FBU authenticator. Reading the extension with the current base matters: inheriting an old packet format from RFC 5268 would be a separate implementation error.

Later SEND work can refine certificates and trust-anchor transport. It does not enlarge the semantic scope of the FBU MAC. Better assurance about the signer makes the narrow claim stronger; it does not turn it into a different claim.

Running code is the proof chain

Lu Heng's Running-Code Primacy asks what actually ran. Here the answer is not “secure mobility.” It is: one CGA address claim, one SEND-signed request, one dedicated encryption public key, one certified router reply, one correlated nonce, one shared-key cache relation, one algorithm, one FBU authenticator and one forwarding decision.

Reality-layer discipline keeps possession, authorization and outcome apart. A private key proves control of a cryptographic operation. SEND validation proves the scoped address claim. A certified router signature identifies the reply source within its trust model. A nonce proves request correlation. A valid FBU MAC authorizes the route change. None of those facts proves device attachment or service continuity.

The abstraction remains reversible only when every green status can return to the exact key purpose, subject relation, generation, algorithm, lifetime and message. When the trail ends at “authenticated,” the system has discarded the very boundary cryptography made strong.

Sources