rfc-4449

Securing Mobile IPv6 Route Optimization Using a Static Shared Key

C. Perkins
date2006-06 streamIETF areaint wgmip6 statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc4449 doi10.17487/RFC4449 errataview
A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS-TRACK]

Extracted elements (19)

design-rationale §2

The mechanism is limited to scenarios where MN and CN are in the same administrative domain, the CN has good reason to trust the MN, and traffic volume is low. Application in the general Internet is typically not possible due to configuration effort and trust requirements.

mobility, security

design-rationale §1

This mechanism uses a preconfigured shared secret between mobile node and correspondent node to eliminate return routability test messages, reducing latency. It provides stronger assurance of home address ownership than the default mechanism but requires manual configuration and limits applicability to trusted, administered environments.

mobility, security, crypto

interoperability-note §1

This mechanism is an alternative to the default return routability test in RFC 3775. Both produce a Kbm used identically for Binding Authorization Data; this variant omits routability test messages by using preconfigured nonces and Kcn instead.

mobility, security

normative-requirement §3 MUST

A correspondent node that uses a precomputable Kbm MUST keep track of the most recent value of the Sequence Number field of Binding Update messages using the precomputable Kbm value, for example by committing it to stable storage, to prevent replay attacks.

mobility, security

normative-requirement §4 MUST

A mobile node MUST use a different value for Kcn for each node in its Binding Update List, and a correspondent node MUST ensure that every mobile node uses a different value of Kcn, so that the sender of a Binding Update can always be uniquely determined.

mobility, security

normative-requirement §3 MUST

Kcn MUST be generated with sufficient randomness as specified in RFC 4086.

mobility, crypto, security

normative-requirement §3 MUST

Keygen tokens MUST be generated from Kcn and the nonces as specified in Mobile IPv6 return routability, and the binding management key Kbm must subsequently be generated from the keygen tokens in the same way.

mobility, crypto, security

normative-requirement §4 MUST

Manually configured keys MUST be used in conformance with RFC 4107. The configured security information is intended to be used ONLY for authenticating Binding Update messages to ensure protection against dictionary attacks.

mobility, security, crypto

normative-requirement §3 SHOULD NOT

The Nonce Indices option SHOULD NOT be present when using precomputable Kbm; if present, the nonce indices supplied SHOULD be ignored and are not included in the authentication data calculation.

mobility, security

normative-requirement §4 MUST

The return routability procedure is RECOMMENDED for all general use and MUST be the default, unless the user explicitly overrides this by entering preconfigured data for a particular peer.

mobility, security

normative-requirement §4 SHOULD

This method SHOULD only be applied between nodes that are under the same administration, because the authorization method does not provide any guarantee that the given care-of address is legitimate.

mobility, security

normative-requirement §2 MUST

Users MUST be able to generate/select a sufficiently good value for Kcn as a precondition for applicability of this mechanism.

mobility, security, crypto

normative-requirement §3 MUST

When a Binding Update is authenticated using a precomputable Kbm, the Binding Authorization Data suboption MUST be present.

mobility, security

normative-requirement §4 SHOULD

When the Sequence Number field rolls over, the parties SHOULD configure a new value for Kcn so that new Kbm values will be computed.

mobility, security

normative-requirement §4 SHOULD NOT

Where a node has been configured to use this mechanism with a particular peer, it SHOULD NOT attempt to use another mechanism even if the peer requests it or claims not to support this mechanism, to prevent bidding down attacks.

mobility, security

protocol-element §3

The preconfigured data consists of: a shared key (Kcn) at least 20 octets long used to generate keygen tokens, a nonce for the care-of keygen token, and a nonce for the home keygen token. This data is associated to the mobile node's home address.

mobility, crypto

security-consideration §2

Because this method does not verify the validity of claimed care-of addresses, it is only applicable where mobile nodes can be trusted not to launch flooding attacks against third parties as described in RFC 4226.

mobility, security

security-consideration §4

If a correspondent node does not track Binding Update sequence numbers, it could accept an old care-of address value. If that address was reallocated to another IPv6 node, that node would be vulnerable to unwanted traffic from the correspondent node.

mobility, security

security-consideration §4

Replay protection for Binding Update messages depends on the 16-bit Sequence Number field; Kbm should not be used for more than 65,536 Binding Updates. If sequence numbers are not protected against reboots, replay attacks become possible. Keys should be rotated when the sequence number rolls over.

mobility, security