Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)
Extracted elements (25)
Key provisioning occurs at an arbitrary time prior to handover, relieving performance overhead on the handover process itself. The CGA from the provisioning exchange names the handover key, so the previous care-of CGA in the FBU acts as the key identifier.
The AR returns the existing handover key if a CGA already has one, rather than generating a new one. This handles the case where an MN returns to a PAR before key expiry and generates the same CGA for its Care-of Address.
The handover key encryption key pair is independent from the SEND CGA key pair and from the actual handover key. This separation follows the purpose-built key architectural principle, ensuring keys are not reused across different security contexts.
If the RtSolPr validates and the CGA is already associated with a shared handover key, the AR MUST return the existing key. If no key exists, the AR MUST construct a new shared handover key, encrypt it with the handover key encryption public key, and insert it into a Handover Key Reply Option in the PrRtAdv.
The AR MUST have a certificate suitable for a SEND-capable router, support SEND certificate discovery, and include a SEND CGA Option and SEND Signature Option in PrRtAdv messages. Mobile nodes MUST be configured with one or more SEND trust anchors.
The AR MUST randomly generate a handover key of sufficient strength to match the authentication algorithm and MUST generate a unique key for each CGA public key. Key generation SHOULD be uncorrelated between handover keys and between handover keys and CGA keys.
The AR MUST set the AT field to the MN's preferred algorithm if supported; otherwise the AR MUST select an algorithm of equivalent or stronger strength. The AR MUST include the SEND nonce from the RtSolPr in the PrRtAdv for anti-replay protection.
The handover key encryption key pair SHOULD be discarded after either HKEPK-LIFETIME (default 12 hours) or HKEPK-HANDOVERS (default 10) handovers, whichever occurs first, to prevent cryptanalysis.
The MN MUST generate a handover key encryption public/private key pair using exactly the same public key algorithm with exactly the same parameters as for SEND. The MN MUST NOT use the key pair for any other encryption or signature operation.
The MN MUST send an RtSolPr containing a Handover Key Request Option with the handover encryption public key. A CGA MUST be the source address, and the MN MUST include the SEND CGA Option and SEND Signature Option. The SEND Nonce MUST also be included for anti-replay protection.
The MN MUST use the matching private key to decrypt the handover key and store it indexed by the AR's IPv6 address and the MN's CGA. Prior to HK-LIFETIME expiring, the MN MUST request a new key from the AR if FMIPv6 service is still required.
The PAR MUST discard the handover key after FMIPv6 forwarding for the previous Care-of Address times out or when HK-LIFETIME expires. The MN SHOULD discard the handover key after MIPv6 binding update is complete on the new AR.
To prevent bidding down attacks from compromised routers, the MN SHOULD NOT request an algorithm weaker than its original request when re-sending the RtSolPr.
Upon receipt of PrRtAdvs with Handover Key Reply Option, the MN MUST first validate them per RFC 3971 and MUST check that the key used to sign the PrRtAdv is the router's certified public key. If a certified key was not used, the message MUST be dropped.
When an FMIPv6-capable AR receives an RtSolPr with a Handover Key Request Option, it MUST first validate the RtSolPr using SEND. If validation fails, the AR MUST NOT include a Handover Key Reply Option and MUST NOT change any existing key record for the address.
When sending an FBU, the MN MUST utilize the handover key and corresponding authentication algorithm to generate an authenticator MAC, and MUST include the old care-of CGA in a Home Address Option.
When the PAR receives an FBU with an authenticator, it MUST find the handover key using the MN's care-of CGA as index and verify the authenticator. If no handover key is found, the PAR MUST NOT change forwarding for the care-of CGA.
The encrypted handover key in the Handover Key Reply Option is the shared handover key encrypted with the MN's handover key encryption public key using RSAES-PKCS1-v1_5 format as specified in RFC 3447.
The handover key encryption public key MUST be formatted according to the same specification as the CGA key in the CGA Parameters Option and MUST have the same parameters as the CGA key, ensuring consistency with the SEND public key algorithm.
Three protocol constants govern key lifetimes: HKEPK-LIFETIME (default 12 hours) for the encryption key pair, HKEPK-HANDOVERS (default 10) for the maximum handover reuse count, and HK-LIFETIME (default 12 hours / 43200 seconds) for the shared handover key.
IANA assigned IPv6 Neighbor Discovery option type codes 27 (Handover Key Request Option) and 28 (Handover Key Reply Option) as defined in this document.
The protocol is subject to replay attacks and DoS attacks using RtSolPr in the same manner as SEND for RS messages. The measures in RFC 3971 for mitigating replay and DoS attacks apply here, including use of SEND nonces for anti-replay.
To avoid state depletion attacks, the handover key SHOULD NOT be generated prior to SEND processing that verifies the originator of the RtSolPr. Mitigations include rate limiting RtSolPr, restricting state for unresolved solicitations, and clever cache management.
The Handover Key Reply Option (Type=28) is a TLV IPv6 Neighbor Discovery option carried in PrRtAdv. It contains Type, Length, Pad Length, 4-bit AT field, 4-bit Reserved, a 16-bit Key Lifetime in seconds, the Encrypted Handover Key (RSA-encrypted using RSAES-PKCS1-v1_5), and Padding.
The Handover Key Request Option (Type=27) is a TLV IPv6 Neighbor Discovery option carried in RtSolPr. It contains an 8-bit Type, 8-bit Length (in units of 8 octets), 8-bit Pad Length, 4-bit AT algorithm type field, 4-bit Reserved field, a variable-length Handover Key Encryption Public Key, and variable-length Padding.