RFC 3972

Cryptographically Generated Addresses (CGA)

📅 published March 2005, from ietf

Cryptographically Generated Addresses (CGA) 🦋

okay bestie, let's get into it 💖 this is RFC 3972, titled Cryptographically Generated Addresses (CGA). It's by T. Aura from Microsoft Research, it's on the Standards Track (so it's a real protocol spec, not just vibes), and it's dated March 2005. The header doesn't list anything it obsoletes or updates, so it's not replacing or patching any earlier RFC 🙌

Status of This Memo ✨

this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🎀 for the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) list. distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2004).

Abstract 🌸

so the big idea is binding a public signature key to an IPv6 address inside the Secure Neighbor Discovery (SEND) protocol 🔐 a Cryptographically Generated Address (CGA) is an IPv6 address where the interface identifier is made by running a cryptographic one-way hash function over a public key plus some auxiliary parameters 🧚

the cool part: anyone can check the binding by recomputing the hash and comparing it to the interface identifier 🙈 messages sent from that address can carry the public key and auxiliary parameters, and get signed with the matching private key 💅 and the whole thing works with no certification authority and no security infrastructure at all. iconic, honestly 👑

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  CGA Parameters and Hash Values . . . . . . . . . . . . . . . .  5
4.  CGA Generation . . . . . . . . . . . . . . . . . . . . . . . .  6
5.  CGA Verification . . . . . . . . . . . . . . . . . . . . . . .  9
6.  CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
    7.1.  Security Goals and Limitations . . . . . . . . . . . . . 12
    7.2.  Hash Extension . . . . . . . . . . . . . . . . . . . . . 13
    7.3.  Privacy Considerations . . . . . . . . . . . . . . . . . 15
    7.4.  Related Protocols  . . . . . . . . . . . . . . . . . . . 15
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    9.1.  Normative References . . . . . . . . . . . . . . . . . . 17
    9.2.  Informative References . . . . . . . . . . . . . . . . . 18
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
    A.  Example of CGA Generation. . . . . . . . . . . . . . . . . 20
    B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statements. . . . . . . . . . . . . . . . . . . . . 22

1. Introduction ✨

okay this section is the setup 🎀 it's about securely tying a cryptographic public key to an IPv6 address in SEND [RFC3971] 💖 the trick is generating the interface identifier (the rightmost 64 bits of the address) by hashing the public key. that address is the CGA, and the matching private key can sign messages sent from it 🔑 if you want intros to CGAs and how they plug into SEND, check out [Aura03] and [AAKMNR02] 📚

this document specifies:

  • how to generate a CGA from the cryptographic hash of a public key and auxiliary parameters,
  • how to verify the association between the public key and the CGA, and
  • how to sign a message sent from the CGA, and how to verify the signature.

to check that an address and a public key actually go together, the verifier needs the address, the public key, and the auxiliary parameter values 🫶 then it can verify messages signed by the key owner (aka the address owner). no public key infrastructure (PKI), certification authorities, or other trusted servers needed. 🙌

plot twist: CGAs aren't certified, so an attacker can make a brand new CGA from any subnet prefix using their own public key (or anyone else's) 💀 BUT the attacker cannot take a CGA that someone else made and send signed messages that look like they came from the real owner. the signature is the lock 🔒

the address format and CGA parameter format are in Sections 2 and 3 🍓 detailed generation and verification algorithms are in Sections 4 and 5. Section 6 covers CGA signatures, generation and verification. and the security considerations in Section 7 are the juicy bit 😭 they cover the limits of CGA-based security, why the hash extension technique exists (to get effective hash lengths above the 64-bit interface identifier limit), what CGAs mean for privacy, and protection against related-protocol attacks 💅

in this document, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119] 🌈 that's the official rulebook for those capitalized words, so read them the way they're meant 🙏

2. CGA Format 🧚

this section is about the address layout 💖 when this doc says "IPv6 address," it means one where the leftmost 64 bits are the subnet prefix and the rightmost 64 bits are the interface identifier [RFC3513] 🦋 we count the interface identifier bits starting from bit zero on the left, so it's easy to point at a specific bit 🎯

a cryptographically generated address (CGA) has a security parameter (Sec) that sets how strong it is against brute-force attacks 💪 Sec is a three-bit unsigned integer, and it lives in the three leftmost bits of the interface identifier (bits 0 - 2). you can write that like this:

   Sec = (interface identifier & 0xe000000000000000) >> 61

the CGA is tied to a set of parameters: a public key and auxiliary parameters 🔐 from those we compute two hash values, Hash1 (64 bits) and Hash2 (112 bits) ✨ the exact formats of the public key and auxiliary parameters, plus how to compute the hashes, are defined in Section 3 🎀

an IPv6 address counts as a cryptographically generated address when it meets these two conditions:

  • The first hash value, Hash1, equals the interface identifier of the address. Bits 0, 1, 2, 6, and 7 (i.e., the bits that encode the security parameter Sec and the "u" and "g" bits from the standard IPv6 address architecture format of interface identifiers [RFC3513]) are ignored in the comparison.
  • The 16*Sec leftmost bits of the second hash value, Hash2, are zero.

if you like bit masks (I do 🙈), the whole definition fits into two of them:

   Mask1 (64 bits)  = 0x1cffffffffffffff

   Mask2 (112 bits) = 0x0000000000000000000000000000  if Sec=0,
                      0xffff000000000000000000000000  if Sec=1,
                      0xffffffff00000000000000000000  if Sec=2,
                      0xffffffffffff0000000000000000  if Sec=3,
                      0xffffffffffffffff000000000000  if Sec=4,
                      0xffffffffffffffffffff00000000  if Sec=5,
                      0xffffffffffffffffffffffff0000  if Sec=6, and
                      0xffffffffffffffffffffffffffff  if Sec=7

so an address is a CGA when both of these equations hold 🌸

   Hash1 & Mask1  ==  interface identifier & Mask1
   Hash2 & Mask2  ==  0x0000000000000000000000000000

that's the foundation, bestie! ✨ more coming in part 2 🫶

3. CGA Parameters and Hash Values ✨

okay so every CGA comes with a CGA Parameters data structure 🎀 and it has this exact layout (don't touch a single bit of it 🙈):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Modifier (16 octets)                     +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Subnet Prefix (8 octets)                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Collision Count|                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   ~                  Public Key (variable length)                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~           Extension Fields (optional, variable length)        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Modifier

This field is a 128-bit unsigned integer, and it can be any value 💜. The modifier gets used during CGA generation to support the hash extension, and it also boosts privacy by adding randomness to the address 🦋.

Subnet Prefix

This field holds the 64-bit subnet prefix of the CGA 🌸.

Collision Count

This is an eight-bit unsigned integer that MUST be 0, 1, or 2 🔥. It gets incremented during CGA generation to recover from an address collision that duplicate address detection catches 💀.

Public Key

This is a variable-length field with the public key of the address owner 🔑. The public key MUST be formatted as a DER-encoded [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo, which is defined in the Internet X.509 certificate profile [RFC3280] 📜. SEND SHOULD use an RSA public/private key pair ✨. When RSA is used, the algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by using the RSAPublicKey type as specified in Section 2.3.1 of RFC 3279 [RFC3279] 🎀. The RSA key length SHOULD be at least 384 bits 💖. Other public key types are undesirable in SEND, since they may cause incompatibilities between implementations 🙃. The length of this field is determined by the ASN.1 encoding.

Extension Fields

This is an optional variable-length field that the current specification doesn't use 🧚. Future versions might use it for extra data items that need to go in the CGA Parameters data structure 🌈. IETF standards action is required to specify the use of the extension fields. Implementations MUST ignore the value of any unrecognized extension fields 🫶.

The two hash values MUST be computed as follows 🧮. The SHA-1 hash algorithm [FIPS.180-1.1995] gets applied to the CGA Parameters. When Hash1 is computed, the input to SHA-1 is the CGA Parameters data structure, and the 64-bit Hash1 is the leftmost 64 bits of the 160-bit SHA-1 hash value 💅. When Hash2 is computed, the input is the same CGA Parameters data structure, except that the subnet prefix and collision count are set to zero 🍓. The 112-bit Hash2 is the leftmost 112 bits of the 160-bit SHA-1 hash value. Also, the hash values are computed over the entire CGA Parameters data structure, including any unrecognized extension fields 👑.

4. CGA Generation 🦋

okay so generating a new CGA takes three inputs 🧁: a 64-bit subnet prefix, the public key of the address owner as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and the security parameter Sec, which is an unsigned three-bit integer. The cost of generating a new CGA goes up exponentially with Sec, and Sec can be anywhere from 0 to 7 📈.

A CGA and its associated parameters SHOULD be generated as follows 🌟:

  1. Set the modifier to a random or pseudo-random 128-bit value 🎲.
  2. Concatenate from left to right the modifier, 9 zero octets, the encoded public key, and any optional extension fields. Run the SHA-1 algorithm on that concatenation, take the 112 leftmost bits of the SHA-1 hash value, and that result is Hash2 🔐.
  3. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are all zero (or if Sec=0), continue with step 4. Otherwise, increment the modifier by one and go back to step 2 🔁.
  4. Set the 8-bit collision count to zero 0️⃣.
  5. Concatenate from left to right the final modifier value, the subnet prefix, the collision count, the encoded public key, and any optional extension fields. Run the SHA-1 algorithm on the concatenation and take the 64 leftmost bits of the SHA-1 hash value. That result is Hash1 🧩.
  6. Form an interface identifier from Hash1 by writing the value of Sec into the three leftmost bits, and by setting bits 6 and 7 (i.e., the "u" and "g" bits) to zero 🪄.
  7. Concatenate the 64-bit subnet prefix and the 64-bit interface identifier to form a 128-bit IPv6 address, with the subnet prefix on the left and the interface identifier on the right, just like a standard IPv6 address [RFC3513] 🌐.
  8. Perform duplicate address detection if required, as per [RFC3971]. If an address collision is detected, increment the collision count by one and go back to step 5. However, after three collisions, stop and report the error 🚨.
  9. Form the CGA Parameters data structure by concatenating from left to right the final modifier value, the subnet prefix, the final collision count value, the encoded public key, and any optional extension fields 🎀.

The output of the address generation algorithm is a new CGA and a CGA Parameters data structure 💖.

The initial value of the modifier in step 1 SHOULD be chosen randomly, so that addresses generated from the same public key are unlinkable. That helps privacy (see Section 7.3) 🙈. The quality of the random number generator does not affect the strength of the binding between the address and the public key, which is a relief 😌. Implementations that don't have strong random numbers available MAY use a non-cryptographic pseudo-random number generator initialized with the current time of day ⏰.

For Sec=0, the algorithm above is deterministic and relatively fast ⚡. Nodes that implement CGA generation MAY always use the security parameter value Sec=0. If Sec=0, steps 2 - 3 of the generation algorithm can be skipped 🏃‍♀️.

For Sec values greater than zero, the algorithm is not guaranteed to finish after a certain number of iterations 😬. The brute-force search in steps 2 - 3 takes O(2^(16*Sec)) iterations to complete. The algorithm was intentionally designed so that generating CGAs with high Sec values is infeasible with current technology 🛡️.

Implementations MAY use optimized or otherwise modified versions of the above algorithm for CGA generation. However, the output of any modified version MUST fulfill the following two requirements 📋. First, the resulting CGA and CGA Parameters data structure MUST be formatted as specified in Sections 2 - 3. Second, the CGA verification procedure defined in Section 5 MUST succeed when invoked on the output of the CGA generation algorithm 💯. Heads up, some optimizations come with trade-offs between privacy and the cost of address generation ⚖️.

One optimization is a big deal. If the subnet prefix of the address changes but the address owner's public key does not, the old modifier value MAY be reused. If it is reused, the algorithm SHOULD be started from step 4. This saves repeating the expensive search for an acceptable modifier value, but in some situations it may make it easier for an observer to link two addresses to each other 👀.

Note that this document does not specify whether duplicate address detection should be performed, or how the detection is done. Step 8 only defines what to do if some form of duplicate address detection is performed and an address collision is detected 🕵️‍♀️.

Future versions of this specification may specify additional inputs to the CGA generation algorithm, concatenated as extension fields to the end of the CGA Parameters data structure. No such extension fields are defined in this document 🌸.

5. CGA Verification ✨

okay so CGA verification is the glow-up check 💅 you give it an IPv6 address plus a CGA Parameters data structure, and it's a yes or a no. The CGA Parameters are basically the modifier, subnet prefix, collision count, public key, and any optional extension fields all stuck together. Either it passes or it fails, no in-between 🫶

The CGA MUST be verified with the following steps:

  1. Check that the collision count in the CGA Parameters data structure is 0, 1, or 2. The CGA verification fails if the collision count is out of the valid range.
  2. Check that the subnet prefix in the CGA Parameters data structure is equal to the subnet prefix (i.e., the leftmost 64 bits) of the address. The CGA verification fails if the prefix values differ.
  3. Execute the SHA-1 algorithm on the CGA Parameters data structure. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1. 🔥
  4. Compare Hash1 with the interface identifier (i.e., the rightmost 64 bits) of the address. Differences in the three leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored. If the 64-bit values differ (other than in the five ignored bits), the CGA verification fails. 🦋
  5. Read the security parameter Sec from the three leftmost bits of the 64-bit interface identifier of the address. (Sec is an unsigned 3-bit integer.) 🎀
  6. Concatenate from left to right the modifier, 9 zero octets, the public key, and any extension fields that follow the public key in the CGA Parameters data structure. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2. 🌸
  7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one of them is not zero, the CGA verification fails. Otherwise, the verification succeeds. (If Sec=0, the CGA verification never fails at this step.) 💜

If the verification fails at any step, the execution of the algorithm MUST be stopped immediately. no exceptions, bestie 🛑 On the other hand, if the verification succeeds, the verifier knows that the public key in the CGA Parameters is the authentic public key of the address owner 👑 The verifier can extract the public key by removing 25 octets from the beginning of the CGA Parameters and by decoding the following SubjectPublicKeyInfo data structure.

Note that the values of bits 6 and 7 (the "u" and "g" bits) of the interface identifier are ignored during CGA verification. In the SEND protocol, after the verification succeeds, the verifier SHOULD process all CGAs in the same way regardless of the Sec, modifier, and collision count values. In particular, the verifier in the SEND protocol SHOULD NOT have any security policy that differentiates between addresses based on the value of Sec. That way, the address generator is free to choose any value of Sec. it's giving fairness 🧚

All nodes that implement CGA verification MUST be able to process all security parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The verification procedure is relatively fast and always requires at most two computations of the SHA-1 hash function. If Sec=0, the verification never fails in steps 6 - 7 and these steps can be skipped ⚡

Nodes that implement CGA verification for SEND SHOULD be able to process RSA public keys that have the algorithm identifier rsaEncryption and key length between 384 and 2,048 bits. Implementations MAY support longer keys. Future versions of this specification may recommend support for longer keys. the future is bright 🌈

Implementations of CGA verification MUST ignore the value of any unrecognized extension fields that follow the public key in the CGA Parameters data structure. However, implementations MUST include any such unrecognized data in the hash input when computing Hash1 in step 3 and Hash2 in step 6 of the CGA verification algorithm. This is important to ensure upward compatibility with future extensions. ignore the vibe but keep the receipts 🫶🍓

6. CGA Signatures

this section is all about how you generate and verify CGA signatures 🖋️ To sign a message, a node needs the CGA, the associated CGA Parameters data structure, the message, and the private cryptographic key that matches the public key in the CGA Parameters. The node also has to have a 128-bit type tag for the message from the CGA Message Type name space.

To sign a message, a node SHOULD do the following:

  • Concatenate the 128-bit type tag (in network byte order) and the message with the type tag to the left and the message to the right. The concatenation is the message to be signed in the next step.
  • Generate the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447] signature algorithm with the SHA-1 hash algorithm. The private key and the concatenation created above are the inputs to the generation operation.

The SEND protocol specification [RFC3971] defines several messages that contain a signature in the Signature Option. The SEND protocol specification also defines a type tag from the CGA Message Type name space. The same type tag is used for all the SEND messages that have the Signature Option. This type tag is an IANA-allocated 128 bit integer that has been chosen at random to prevent an accidental type collision with messages of other protocols that use the same public key but that may or may not use IANA-allocated type tags. it's random on purpose, so nobody's messages get mixed up 🎲✨

The CGA, the CGA Parameters data structure, the message, and the signature are sent to the verifier. The SEND protocol specification defines how these data items are sent in SEND protocol messages. Note that the 128-bit type tag is not included in the SEND protocol messages because the verifier knows its value implicitly from the ICMP message type field in the SEND message. See the SEND specification [RFC3971] for precise information about how SEND handles the type tag. 🧠

To verify a signature, the verifier needs the CGA, the associated CGA Parameters data structure, the message, and the signature. The verifier also needs to have the 128-bit type tag for the message.

To verify the signature, a node SHOULD do the following:

  • Verify the CGA as defined in Section 5. The inputs to the CGA verification are the CGA and the CGA Parameters data structure.
  • Concatenate the 128-bit type tag and the message with the type tag to the left and the message to the right. The concatenation is the message whose signature is to be verified in the next step.
  • Verify the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447] algorithm with the SHA-1 hash algorithm. The inputs to the verification operation are the public key (i.e., the RSAPublicKey structure from the SubjectPublicKeyInfo structure that is a part of the CGA Parameters data structure), the concatenation created above, and the signature.

The verifier MUST accept the signature as authentic only if both the CGA verification and the signature verification succeed. two checks, zero shortcuts 💅

7. Security Considerations 🔐

7.1. Security Goals and Limitations

okay this is the serious part, so let's go 🥹 The purpose of CGAs is to prevent stealing and spoofing of existing IPv6 addresses. The public key of the address owner is bound cryptographically to the address. The address owner can use the corresponding private key to assert its ownership and to sign SEND messages sent from the address.

It is important to understand that an attacker can create a new address from an arbitrary subnet prefix and its own (or someone else's) public key because CGAs are not certified. However, the attacker cannot impersonate somebody else's address. This is because the attacker would have to find a collision of the cryptographic hash value Hash1. (The property of the hash function needed here is called second pre-image resistance [MOV97].) main character energy, the hash is the bouncer 🚪💀

For each valid CGA Parameters data structure, there are 4*(Sec+1) different CGAs that match the value. This is because decrementing the Sec value in the three leftmost bits of the interface identifier does not invalidate the address, and the verifier ignores the values of the "u" and "g" bits. In SEND, this does not have any security or implementation implications. 🙈

Another limitation of CGAs is that there is no mechanism for proving that an address is not a CGA. Thus, an attacker could take someone else's CGA and present it as a non-cryptographically generated address (e.g., as an RFC 3041 address [RFC3041]). An attacker does not benefit from this because although SEND nodes accept both signed and unsigned messages from every address, they give priority to the information in the signed messages. 🫣

The minimum RSA key length required for SEND is only 384 bits. So short keys are vulnerable to integer-factoring attacks and cannot be used for strong authentication or secrecy. On the other hand, the cost of factoring 384-bit keys is currently high enough to prevent most denial-of-service attacks. Implementations that initially use short RSA keys SHOULD be prepared to switch to longer keys when denial-of-service attacks arising from integer factoring become a problem.

⚠️ short keys are a real risk, so don't just vibe with 384 bits forever. be ready to level up to longer keys when factoring attacks start getting spicy 🔥

The impact of a key compromise on CGAs depends on the application for which they are used. In SEND, it is not a major concern. If the private signature key is compromised because the SEND node has itself been compromised, the attacker does not need to spoof SEND messages from the node. When it is discovered that a node has been compromised, a new signature key and a new CGA SHOULD be generated.

On the other hand, if the RSA key is compromised because integer-factoring attacks for the chosen key length have become practical, the key has to be replaced with a longer one, as explained above. In either case, the address change effectively revokes the old public key. It is not necessary to have any additional key revocation mechanism or to limit the lifetimes of the signature keys. no extra revocation drama needed, the new address is the reset button 🦋✨

7.2. Hash Extension ✨

okay so as computers get faster, the 64 bits of the interface identifier won't be enough to stop attackers from hunting for hash collisions 😭. it helps a little that the subnet prefix is included in the hash input 🧚. that stops an attacker from using one precomputed database to go after addresses with different subnet prefixes. they'd need a separate database for each subnet prefix. link-local addresses are still vulnerable tho 💀 because every IPv6 node uses the same prefix.

to keep CGA from getting outdated as computers speed up, the hash technique used to generate CGAs must be extended somehow 💅. the chosen move is to increase the cost of both address generation and brute-force attacks by the same parameterized factor, while keeping the cost of address use and verification constant 🦋. this also protects link-local addresses ✨. the hash extension is the main difference between this document and earlier CGA proposals [OR01][Nik01][MC02] 👑.

here's how the extension works. the input to the second hash function, Hash2, gets modified (by changing the modifier value) until the leftmost 16*Sec bits of the hash value are zero 🔥. this bumps up the cost of address generation by approximately a factor of 2^(16*Sec), and it bumps up the cost of brute-force attacks by that same factor. so creating a CGA Parameters data structure that binds the attacker's public key with somebody else's address goes from O(2^59) to O(2^(59+16*Sec)). the address generator picks the security parameter Sec based on its own computational capacity, the perceived risk of attacks, and how long the address is expected to live 🎀. right now, Sec values between 0 and 2 are sufficient for most IPv6 nodes, and higher Sec values will slowly become useful as computers get faster 🌈.

theoretically, if no hash extension is used (i.e., Sec=0) and a typical attacker can tap into N local networks at the same time, an attack against link-local addresses is N times as efficient as an attack against addresses of a specific network 😱. you can counter that by using a slightly higher Sec value for link-local addresses. once higher Sec values (such that 2^(16*Sec) > N) are used for all addresses, the relative advantage of attacking link-local addresses becomes insignificant 🙈.

the hash extension only works if the computational capacities of the attacker and the address generator grow at the same (potentially exponential) rate 🤔. that's not necessarily true if addresses are generated on low-end mobile devices, where the main design goals are to lower cost and decrease size instead of increasing computing power. but there's no reason to do that. the expensive part of address generation (steps 1 - 3 of the generation algorithm) may be delegated to a more powerful computer 🫶. and that work can be done in advance or offline, instead of in real time when a new address is needed ⭐.

so, to let mobile nodes whose subnet prefixes change frequently use Sec values greater than zero, we decided not to include the subnet prefix in the input of Hash2 🦋. the result is weaker than it would be if the subnet prefix were included in the input of both hashes. on the other hand, our scheme is at least as strong as using the hash extension technique without including the subnet prefix in either hash. it's also at least as strong as not using the hash extension but including the subnet prefix. this trade-off was made because mobile nodes frequently move to insecure networks, where they are at risk of denial-of-service (DoS) attacks (for example, during the duplicate address detection procedure) 😬.

in most networks, the goal of Secure Neighbor Discovery and CGA signatures is to prevent denial-of-service attacks 🛡️. so it's usually sensible to start with a low Sec value and only replace addresses with stronger ones when denial-of-service attacks based on brute-force search become a significant problem. if CGAs are part of a strong authentication or secrecy mechanism, it might be necessary to start with higher Sec values 👑.

the collision count value is used to modify the input to Hash1 if there is an address collision. it's important not to allow collision count values higher than 2 🚫. first, it's extremely unlikely that three collisions would occur, and the reason is certain to be either a configuration or implementation error or a denial-of-service attack. (when the SEND protocol is used, deliberate collisions caused by a DoS attacker are detected and ignored 💅.) second, an attacker doing a brute-force search to match a given CGA can try all different values of a collision count without repeating the brute-force search for the modifier value. so if higher values are allowed for the collision count, the hash extension technique becomes less effective at preventing brute-force attacks 💀.

7.3. Privacy Considerations 🦋

CGAs can give the same level of pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [RFC3041] 🎀. an IP host can generate multiple pseudo-random CGAs by running the CGA generation algorithm of Section 4 multiple times, using a different random or pseudo-random initial value for the modifier every time. the host should change its address periodically, as in [RFC3041] 🔄. when privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values 🔐. advice on random number generation can be found in [RFC1750] 📚.

there are two apparent limitations to this privacy protection 👀. however, as explained below, neither is very serious 💖.

first, the high cost of address generation may stop hosts that use a high Sec value from changing their address frequently. this is mitigated because the expensive part of address generation may be done in advance or offline, as explained in the previous section 🧚. it's also worth noting that the nodes that benefit most from high Sec values (e.g., DNS servers, routers, and data servers) usually don't need pseudonymity, and the nodes with high privacy requirements (e.g., client PCs and mobile hosts) are unlikely targets for expensive brute-force DoS attacks and can make do with lower Sec values 🌸.

second, the public key of the address owner is revealed in the signed SEND messages. this means that if the address owner wants to be pseudonymous toward the nodes on the local links it accesses, it should generate not only a new address but also a new public key 🙈. with typical local-link technologies, though, a node's link-layer address is a unique identifier for the node. as long as the node keeps using the same link-layer address, it makes little sense to change the public key for privacy reasons 🤷‍♀️.

although this document defines CGAs only for the purposes of Secure Neighbor Discovery, other protocols could be defined elsewhere that use the same addresses and public keys 🌈. this raises the possibility of related-protocol attacks, in which a signed message from one protocol is replayed in another protocol. that means other protocols (perhaps even ones designed without intimate knowledge of SEND) could endanger the security of SEND 😱. what makes this threat even more significant is that the attacker could create a CGA from someone else's public key and then replay signed messages from a protocol that has nothing to do with CGAs or IP addresses 💀.

to prevent related-protocol attacks, a type tag is prepended to every message before it is signed. the type tags are 128-bit randomly chosen values, which prevents accidental type collisions even with poorly designed protocols that don't use any type tags 🎀. moreover, the SEND protocol includes the sender's CGA address in all signed messages. this makes it even more difficult for an attacker to take signed messages from some other context and replay them as SEND messages 🔒.

finally, a strong cautionary note has to be made about using CGA signatures for purposes other than SEND ⚠️. first, the other protocols MUST include a type tag and the sender address in all signed messages, in the same way SEND does. each protocol MUST define its own type tag values, as explained in Section 8. moreover, because of the possibility of related-protocol attacks, the public key MUST be used only for signing, and it MUST NOT be used for encryption 🚫. second, the minimum RSA key length of 384 bits may be too short for many applications, and the impact of key compromise on the particular protocol must be evaluated 🔑. third, CGA-based authorization is particularly suitable for securing neighbor discovery [RFC2461] and duplicate address detection [RFC2462], because these are network-layer signaling protocols for which IPv6 addresses are natural endpoint identifiers 👑. in any protocol that uses other identifiers, such as DNS names, CGA signatures alone are not a sufficient security mechanism. there must also be a secure way of mapping the other identifiers to IPv6 addresses 🗺️. if the goal is not to verify claims about IPv6 addresses, CGA signatures are probably not the right solution 🙅‍♀️.

8. IANA Considerations 📋

this document defines a new CGA Message Type name space for use as type tags in messages that may be signed using CGA signatures 🏷️. the values in this name space are 128-bit unsigned integers. values in this name space are allocated on a First Come First Served basis [RFC2434]. IANA assigns new 128-bit values directly, without a review ✨.

the requester SHOULD generate the new values with a strong random-number generator 🎲. continuous ranges of at most 256 values can be requested, provided that the 120 most significant bits of the values have been generated with a strong random-number generator 💖.

IANA does not generate random values for the requester 🙅‍♀️. IANA allocates requested values without verifying how they were generated. the name space is essentially unlimited, and any number of individual values and ranges of at most 256 values can be allocated 🌌.

CGA Message Type values for private use MAY be generated with a strong random-number generator without IANA allocation 🔐.

this document does not define any new values in any name space 🦋.

9. References 📚

9.1. Normative References

okay so these are the must-read-first docs, bestie 📚✨ if you want the full picture you need every one of these:

  • [RFC3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
  • [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
  • [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [ITU.X690.2002] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
  • [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
  • [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [FIPS.180-1.1995] National Institute of Standards and Technology, "Secure Hash Standard", Federal Information Processing Standards Publication FIPS PUB 180-1, April 1995, http://www.itl.nist.gov/fipspubs/fip180-1.htm.

9.2. Informative References

these ones are the deep-dive reading list 🦋 super useful if you want the backstory, but you don't need them to get the spec:

  • [AAKMNR02] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P., and M. Roe, "Securing IPv6 neighbor discovery and router discovery", ACM Workshop on Wireless Security (WiSe 2002), Atlanta, GA USA, September 2002.
  • [Aura03] Aura, T., "Cryptographically Generated Addresses (CGA)", 6th Information Security Conference (ISC'03), Bristol, UK, October 2003.
  • [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
  • [MOV97] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997.
  • [MC02] Montenegro, G. and C. Castelluccia, "Statistically unique and cryptographically verifiable identifiers and addresses", ISOC Symposium on Network and Distributed System Security (NDSS 2002), San Diego, CA USA, February 2002.
  • [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
  • [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [Nik01] Nikander, P., "A scaleable architecture for IPv6 address ownership", draft-nikander-addr-ownership-00 (work in progress), March 2001.
  • [OR01] O'Shea, G. and M. Roe, "Child-proof authentication for MIPv6 (CAM)", ACM Computer Communications Review 31(2), April 2001.
  • [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.

Appendix A. Example of CGA Generation ✨

this is the walkthrough I'd want to see if I were trying to make a CGA by hand 🧚 we start with a CGA with Sec=1, using the subnet prefix fe80:: and this public key:

305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001

the modifier starts off at a random value, 89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a. the input to Hash2 is:

89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a 0000 0000 0000 0000 00
305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001

the 112 first bits of the SHA-1 hash of that input come out to Hash2=436b 9a70 dbfd dbf1 926e 6e66 29c0. oof, that does not begin with 16*Sec=16 zero bits 😭 so we bump the modifier up by one and recompute. the new input to Hash2 is:

89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b 0000 0000 0000 0000 00
305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001

the new hash value is Hash2=0000 01ca 680b 8388 8d09 12df fcce. the 16 leftmost bits of Hash2 are all zero, so we found a suitable modifier 🎉 (we were very lucky to find it so soon.)

the input to Hash1 is:

89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b fe80 0000 0000 0000 00
305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241
00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16
467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773
c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001

the 64 first bits of the SHA-1 hash of that input are Hash1=fd4a 5bf6 ffb4 ca6c. now we build the interface identifier from it: write Sec=1 into the three leftmost bits, and set bits 6 and 7 (the "u" and "g" bits) to zero. that gives us 3c4a:5bf6:ffb4:ca6c 💜

last step, we put it together into the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. that's our new CGA! 👑 no address collisions were detected this time. (collisions are very rare.) and the CGA Parameters data structure tied to the address is the same as the input to Hash1 above. main character energy, honestly 💅

Appendix B. Acknowledgements 🫶

the author gratefully acknowledges the contributions of Jari Arkko, Francis Dupont, Pasi Eronen, Christian Huitema, James Kempf, Pekka Nikander, Michael Roe, Dave Thaler, and other participants of the SEND working group. so many legends in one list, iconic 🌈

Author's Address

Tuomas Aura
Microsoft Research
Roger Needham Building
7 JJ Thomson Avenue
Cambridge  CB3 0FB
United Kingdom

Phone: +44 1223 479708
EMail: tuomaura@microsoft.com

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

the legal bit, but it matters 🎀

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸

📦 where this page comes from