Cryptographically Generated Addresses (CGA)
updated by
Extracted elements (27)
The collision count is capped at 2 because three collisions almost certainly indicate a configuration error or denial-of-service attack rather than a genuine collision. Allowing higher values would weaken the hash extension: an attacker could try all collision count values without repeating the modifier search.
The hash extension technique uses a brute-force search over a Modifier value until 16*Sec leading bits of Hash2 are zero, increasing attack cost by O(2^(16*Sec)) while keeping verification cost constant (at most two SHA-1 evaluations). This allows the security parameter to be raised as computing power increases.
The subnet prefix is deliberately excluded from the Hash2 input (used only for Hash1) so that mobile nodes with frequently changing prefixes can reuse an already-computed modifier value and avoid repeating the expensive brute-force search. The trade-off is slightly weaker Hash2 binding compared to including the prefix in both hashes.
Other protocols that use CGA signatures MUST define their own type tag values in the CGA Message Type name space, include the sender's CGA address in all signed messages, and evaluate whether the 384-bit minimum RSA key length is sufficient for their security requirements.
After successful CGA verification in SEND, the verifier SHOULD NOT apply security policy that differentiates between addresses based on the Sec value, so address generators are free to choose any Sec.
All nodes implementing CGA verification MUST be able to process all security parameter values Sec = 0 through 7. Verification requires at most two SHA-1 computations.
CGA verification MUST follow seven steps: check collision count in [0,2]; verify subnet prefix matches; compute Hash1 and compare to interface identifier (ignoring bits 0–2, 6–7); read Sec from address; compute Hash2; verify 16*Sec leftmost bits of Hash2 are zero. Execution MUST stop immediately on any failure.
Extension fields in the CGA Parameters data structure are reserved for future use; IETF standards action is required to define their use. Implementations MUST ignore unrecognized extension fields but MUST include them in hash computations for both Hash1 and Hash2.
Nodes implementing CGA verification for SEND SHOULD be able to process RSA public keys with algorithm identifier rsaEncryption and key lengths between 384 and 2048 bits; implementations MAY support longer keys.
The Collision Count field in CGA Parameters MUST be 0, 1, or 2. CGA verification fails if the collision count is outside this range.
The initial modifier value SHOULD be chosen randomly so that addresses generated from the same public key are unlinkable, enhancing privacy. Implementations without strong random numbers MAY use a pseudo-random generator initialized with current time of day.
The Public Key field MUST be formatted as a DER-encoded ASN.1 SubjectPublicKeyInfo structure per RFC 3280. SEND SHOULD use RSA, with algorithm identifier rsaEncryption (OID 1.2.840.113549.1.1.1) and RSAPublicKey type per RFC 3279. The RSA key length SHOULD be at least 384 bits.
The verifier MUST accept a CGA signature as authentic only if both the CGA verification (Section 5) and the RSA signature verification succeed.
CGAs can provide the same level of pseudonymity as RFC 3041 privacy extensions: hosts generate multiple CGAs using different random initial modifier values. When privacy protection is needed, the random number generator SHOULD be strong enough to produce unpredictable, unlinkable values.
The public key of the address owner is revealed in signed SEND messages. A node that requires pseudonymity toward local-link neighbors must generate both a new address and a new public key, though link-layer address reuse typically already identifies the node uniquely.
A CGA satisfies two conditions: Hash1 (64-bit) must equal the interface identifier (ignoring bits 0–2, 6–7), and the 16*Sec leftmost bits of Hash2 (112-bit) must be zero. These conditions are expressed via Mask1=0x1cffffffffffffff and Sec-dependent Mask2 values.
A CGA signature is produced by prepending a 128-bit type tag (from the CGA Message Type name space) to the message and signing the concatenation using RSASSA-PKCS1-v1_5 with SHA-1. The verifier MUST first verify the CGA itself, then verify the RSA signature over the same concatenation.
Hash1 (64-bit) is the leftmost 64 bits of the SHA-1 hash of the full CGA Parameters data structure. Hash2 (112-bit) is the leftmost 112 bits of the SHA-1 hash of CGA Parameters with subnet prefix and collision count zeroed out. Both hashes include any unrecognized extension fields.
The CGA Message Type name space provides 128-bit type tags prepended to signed messages to prevent cross-protocol replay attacks. The randomly chosen 128-bit values prevent accidental collisions even with protocols that use no type tagging.
This document defines the CGA Message Type name space of 128-bit unsigned integers, allocated on a First Come First Served basis. Requesters SHOULD generate values with a strong random-number generator; continuous ranges of at most 256 values may be requested if the 120 most significant bits are randomly generated. Values for private use MAY be self-assigned without IANA allocation.
CGAs are not certified, so an attacker can create a new CGA from an arbitrary subnet prefix and any public key. However, an attacker cannot impersonate an existing CGA without finding a second pre-image of Hash1, which is computationally infeasible.
If the private key is compromised, a new signature key and new CGA SHOULD be generated. Address change effectively revokes the old public key; no additional key revocation mechanism is needed.
The minimum RSA key length for SEND is 384 bits, which is vulnerable to integer-factoring attacks. Implementations that use short RSA keys SHOULD be prepared to switch to longer keys when factoring-based denial-of-service attacks become practical.
To prevent related-protocol attacks (replay of a message signed for one protocol as a message in another), every protocol using CGA signatures MUST prepend a protocol-specific 128-bit type tag to all signed messages and MUST include the sender's CGA address. The public key MUST be used only for signing and MUST NOT be used for encryption.
CGA generation: (1) set Modifier to random 128-bit value; (2) compute Hash2 over modifier + 9 zero octets + public key; (3) if 16*Sec leftmost bits of Hash2 are nonzero, increment modifier and repeat; (4) set collision count to 0; (5) compute Hash1; (6) form interface identifier with Sec and cleared u/g bits; (7) form address; (8) if DAD collision, increment collision count (max 2) and retry from step 5.
The CGA interface identifier (rightmost 64 bits) encodes the security parameter Sec in the three leftmost bits (bits 0–2): Sec = (interface identifier & 0xe000000000000000) >> 61. Bits 6 and 7 are the standard IPv6 'u' and 'g' bits and are set to zero.
The CGA Parameters data structure contains: Modifier (16 octets, 128-bit unsigned integer), Subnet Prefix (8 octets), Collision Count (1 octet), Public Key (variable-length DER-encoded SubjectPublicKeyInfo), and optional Extension Fields (variable length).