Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)
updates
- rfc-3972 — Cryptographically Generated Addresses (CGA)
Extracted elements (15)
Because only 8 Sec values exist (3 bits), Sec value reuse may eventually be necessary when old values are fully abandoned due to weak security. However, reuse is explicitly a last resort and requires a long deprecation period to prevent misinterpretation by old implementations.
Current CGA applications (SEND, shim6, Mobile IPv6) rely on CGAs only to prove address ownership against third-party attackers, not to provide non-repudiation between peers. Because collision attacks require the attacker to generate both colliding messages, they do not enable new attacks against these ownership-proof use cases.
Multiple hash algorithm support is added for two forward-looking reasons: future CGA applications may require stronger collision resistance than SHA-1 provides, and the recent attacks demonstrate that protocols must be able to migrate away from compromised hash functions without major disruption.
The document deliberately does not assign hash functions to non-SHA-1 Sec values, because it is not yet clear that new assignments are needed or which hash function should be selected; those decisions are deferred to future Standards Action documents.
The Sec bits were chosen to encode the hash algorithm used rather than consuming additional hash bits (which would weaken security by reducing hash entropy in the address) or the 'u'/'g' bits (which are reserved for unique interface identifier purposes and have been honored by all existing mechanisms).
If Sec value reuse is ever adopted, implementations using the old and new meanings of the same Sec value cannot interoperate: CGA verification fails in the worst case and both nodes revert to unprotected IPv6 addresses. This affects only obsolete, already-insecure CGA parameter sets.
Sec value 000 is backward compatible with RFC 3972 (SHA-1, no hash2 bits forced to zero), ensuring existing CGA implementations continue to interoperate with implementations of this updated specification.
An implementation MUST NOT simultaneously support two different meanings of a Sec value.
The RFC defining the CGA generation procedure for a given Sec value MUST explicitly define the minimum acceptable key length for CGAs with that Sec value, so that hash and public-key protection are coherent.
When generating a CGA, the CGA generation procedure defined in the RFC pointed to by the corresponding CGA SEC registry entry MUST be used.
The 3-bit Sec field in the CGA interface identifier encodes both brute-force attack protection level and the hash algorithm used. Sec=000 means SHA-1 with 0 hash2 bits forced to zero; Sec=001 means SHA-1 with 16 hash2 bits forced to zero; Sec=010 means SHA-1 with 32 hash2 bits forced to zero. Other Sec values may designate alternative hash functions per the CGA SEC registry.
The CGA generation procedure for a new Sec value may require a longer Modifier value than currently defined if the required number of leading zero bits in hash2 exceeds the current 112-bit bound defined in RFC 3972.
This document creates the 'CGA SEC' registry maintained by IANA for the 3-bit Sec field defined in RFC 3972. Future assignments require Standards Action. Each entry records a name, the 3-bit value, and the RFC defining the corresponding CGA generation procedure. Initial values: SHA-1_0hash2bits=000, SHA-1_16hash2bits=001, SHA-1_32hash2bits=010.
Encoding the hash function only inside the CGA Parameter Data Structure is vulnerable to downgrading attacks: an attacker can find an alternative CGA_PDS using a weaker hash function that produces the same address value, defeating the stronger hash's protection. Therefore, the hash algorithm must be encoded in the address itself.
The document is motivated by and addresses protection against attacks on hash functions used in CGAs, specifically SHA-1 collision attacks, by providing a migration path to alternative hash algorithms via the CGA SEC registry.