diff options
Diffstat (limited to 'doc/rfc/rfc3972.txt')
| -rw-r--r-- | doc/rfc/rfc3972.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc3972.txt b/doc/rfc/rfc3972.txt new file mode 100644 index 0000000..9c7a7ab --- /dev/null +++ b/doc/rfc/rfc3972.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group T. Aura +Request for Comments: 3972 Microsoft Research +Category: Standards Track March 2005 + + + Cryptographically Generated Addresses (CGA) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes a method for binding a public signature key + to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. + Cryptographically Generated Addresses (CGA) are IPv6 addresses for + which the interface identifier is generated by computing a + cryptographic one-way hash function from a public key and auxiliary + parameters. The binding between the public key and the address can + be verified by re-computing the hash value and by comparing the hash + with the interface identifier. Messages sent from an IPv6 address + can be protected by attaching the public key and auxiliary parameters + and by signing the message with the corresponding private key. The + protection works without a certification authority or any security + infrastructure. + + + + + + + + + + + + + + + + + + +Aura Standards Track [Page 1] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + +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 + + This document specifies a method for securely associating a + cryptographic public key with an IPv6 address in the Secure Neighbor + Discovery (SEND) protocol [RFC3971]. The basic idea is to generate + the interface identifier (i.e., the rightmost 64 bits) of the IPv6 + address by computing a cryptographic hash of the public key. The + resulting IPv6 address is called a cryptographically generated + address (CGA). The corresponding private key can then be used to + sign messages sent from the address. An introduction to CGAs and + their application to SEND can be found in [Aura03] and [AAKMNR02]. + + This document specifies: + + o how to generate a CGA from the cryptographic hash of a public key + and auxiliary parameters, + + o how to verify the association between the public key and the CGA, + and + + o how to sign a message sent from the CGA, and how to verify the + signature. + + + + + + +Aura Standards Track [Page 2] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + To verify the association between the address and the public key, the + verifier needs to know the address itself, the public key, and the + values of the auxiliary parameters. The verifier can then go on to + verify messages signed by the owner of the public key (i.e., the + address owner). No additional security infrastructure, such as a + public key infrastructure (PKI), certification authorities, or other + trusted servers, is needed. + + Note that because CGAs themselves are not certified, an attacker can + create a new CGA from any subnet prefix and its own (or anyone + else's) public key. However, the attacker cannot take a CGA created + by someone else and send signed messages that appear to come from the + owner of that address. + + The address format and the CGA parameter format are defined in + Sections 2 and 3. Detailed algorithms for generating addresses and + for verifying them are given in Sections 4 and 5, respectively. + Section 6 defines the procedures for generating and verifying CGA + signatures. The security considerations in Section 7 include + limitations of CGA-based security, the reasoning behind the hash + extension technique that enables effective hash lengths above the + 64-bit limit of the interface identifier, the implications of CGAs on + 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]. + +2. CGA Format + + When talking about addresses, this document refers to IPv6 addresses + in which the leftmost 64 bits of a 128-bit address form the subnet + prefix and the rightmost 64 bits of the address form the interface + identifier [RFC3513]. We number the bits of the interface identifier + starting from bit zero on the left. + + A cryptographically generated address (CGA) has a security parameter + (Sec) that determines its strength against brute-force attacks. The + security parameter is a three-bit unsigned integer, and it is encoded + in the three leftmost bits (i.e., bits 0 - 2) of the interface + identifier. This can be written as follows: + + Sec = (interface identifier & 0xe000000000000000) >> 61 + + + + + + + + +Aura Standards Track [Page 3] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + The CGA is associated with a set of parameters that consist of a + public key and auxiliary parameters. Two hash values Hash1 (64 bits) + and Hash2 (112 bits) are computed from the parameters. The formats + of the public key and auxiliary parameters, and the way to compute + the hash values, are defined in Section 3. + + A cryptographically generated address is defined as an IPv6 address + that satisfies the following two conditions: + + o 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. + + o The 16*Sec leftmost bits of the second hash value, Hash2, are + zero. + + The above definition can be stated in terms of the following two bit + masks: + + 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 + + A cryptographically generated address is an IPv6 address for which + the following two equations hold: + + Hash1 & Mask1 == interface identifier & Mask1 + Hash2 & Mask2 == 0x0000000000000000000000000000 + + + + + + + + + + + + + + +Aura Standards Track [Page 4] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + +3. CGA Parameters and Hash Values + + Each CGA is associated with a CGA Parameters data structure, which + has the following format: + + 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 contains a 128-bit unsigned integer, which can be any + value. The modifier is used during CGA generation to implement + the hash extension and to enhance privacy by adding randomness to + the address. + + Subnet Prefix + + This field contains the 64-bit subnet prefix of the CGA. + + Collision Count + + This is an eight-bit unsigned integer that MUST be 0, 1, or 2. + The collision count is incremented during CGA generation to + recover from an address collision detected by duplicate address + detection. + + + +Aura Standards Track [Page 5] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + Public Key + + This is a variable-length field containing 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, + 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, as they may result + in 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 is not used in the + current specification. Future versions of this specification may + use this field for additional data items that need to be included + 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] is applied to the CGA Parameters. When + Hash1 is computed, the input to the SHA-1 algorithm is the CGA + Parameters data structure. The 64-bit Hash1 is obtained by taking + 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 obtained by taking the leftmost 112 bits of the + 160-bit SHA-1 hash value. Note that the hash values are computed + over the entire CGA Parameters data structure, including any + unrecognized extension fields. + +4. CGA Generation + + The process of generating a new CGA takes three input values: 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 depends exponentially on the security + parameter Sec, which can have values from 0 to 7. + + + + + + +Aura Standards Track [Page 6] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + A CGA and 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. Execute + the SHA-1 algorithm on the concatenation. Take the 112 leftmost + bits of the SHA-1 hash value. The 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. + + 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. Execute the SHA-1 algorithm on the + concatenation. Take the 64 leftmost bits of the SHA-1 hash value. + The 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 + to the left and interface identifier to the right, as in 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 + to make addresses generated from the same public key unlinkable, + which enhances privacy (see Section 7.3). The quality of the random + number generator does not affect the strength of the binding between + + + + +Aura Standards Track [Page 7] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + the address and the public key. Implementations that have no strong + random numbers available MAY use a non-cryptographic pseudo-random + number generator initialized with the current time of day. + + For Sec=0, the above algorithm 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 above algorithm is not + guaranteed to terminate after a certain number of iterations. The + brute-force search in steps 2 - 3 takes O(2^(16*Sec)) iterations to + complete. The algorithm has been intentionally designed so that the + generation of 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 versions 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. Note that some + optimizations involve trade-offs between privacy and the cost of + address generation. + + One optimization is particularly important. 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 optimization avoids repeating + the expensive search for an acceptable modifier value but may, in + some situations, 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 and 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 that are concatenated as extension + fields to the end of the CGA Parameters data structure. No such + extension fields are defined in this document. + + + + + + + + +Aura Standards Track [Page 8] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + +5. CGA Verification + + CGA verification takes an IPv6 address and a CGA Parameters data + structure as input. The CGA Parameters consist of the concatenated + modifier, subnet prefix, collision count, public key, and optional + extension fields. The verification either succeeds or fails. + + 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. 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 + + + + + +Aura Standards Track [Page 9] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + 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. + + 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. + + 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. + +6. CGA Signatures + + This section defines the procedures for generating and verifying 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 corresponds to the public key in the CGA + Parameters. The node also must 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: + + o 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. + + + +Aura Standards Track [Page 10] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + o 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. + + 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: + + o Verify the CGA as defined in Section 5. The inputs to the CGA + verification are the CGA and the CGA Parameters data structure. + + o 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. + + o 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. + + + + + + +Aura Standards Track [Page 11] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + +7. Security Considerations + +7.1. Security Goals and Limitations + + 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].) + + 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. + + 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. + + + +Aura Standards Track [Page 12] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + 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. + +7.2. Hash Extension + + As computers become faster, the 64 bits of the interface identifier + will not be sufficient to prevent attackers from searching for hash + collisions. It helps somewhat that we include the subnet prefix of + the address in the hash input. This prevents the attacker from using + a single pre-computed database to attack addresses with different + subnet prefixes. The attacker needs to create a separate database + for each subnet prefix. Link-local addresses are, however, left + vulnerable because the same prefix is used by all IPv6 nodes. + + To prevent the CGA technology from becoming outdated as computers + become faster, the hash technique used to generate CGAs must be + extended somehow. The chosen extension technique 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 provides protection for link-local + addresses. Introduction of the hash extension is the main difference + between this document and earlier CGA proposals [OR01][Nik01][MC02]. + + To achieve the effective extension of the hash length, the input to + the second hash function, Hash2, is modified (by changing the + modifier value) until the leftmost 16*Sec bits of the hash value are + zero. This increases the cost of address generation approximately by + a factor of 2^(16*Sec). It also increases the cost of brute-force + attacks by the same factor. That is, the cost of creating a CGA + Parameters data structure that binds the attacker's public key with + somebody else's address is increased from O(2^59) to + O(2^(59+16*Sec)). The address generator may choose the security + parameter Sec depending on its own computational capacity, the + perceived risk of attacks, and the expected lifetime of the address. + Currently, Sec values between 0 and 2 are sufficient for most IPv6 + nodes. As computers become faster, higher Sec values will slowly + become useful. + + Theoretically, if no hash extension is used (i.e., Sec=0) and a + typical attacker is able to 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. The effect + could be countered by using a slightly higher Sec value for link- + + + + +Aura Standards Track [Page 13] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + local addresses. When 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 effectiveness of the hash extension depends on the assumption + that the computational capacities of the attacker and the address + generator will grow at the same (potentially exponential) rate. This + is not necessarily true if the addresses are generated on low-end + mobile devices, for which the main design goals are to lower cost and + decrease size, rather than increase computing power. But there is no + reason for doing so. The expensive part of the address generation + (steps 1 - 3 of the generation algorithm) may be delegated to a more + powerful computer. Moreover, this work can be done in advance or + offline, rather than in real time, when a new address is needed. + + To make it possible for mobile nodes whose subnet prefixes change + frequently to use Sec values greater than zero, we have 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 is 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 the 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. Therefore, it is + usually sensible to start by using a low Sec value and to replace + addresses with stronger ones only when denial-of-service attacks + based on brute-force search become a significant problem. If CGAs + were used as a 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 is important not to allow + collision count values higher than 2. First, it is 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. Thus, if higher + values are allowed for the collision count, the hash extension + technique becomes less effective in preventing brute force attacks. + + + +Aura Standards Track [Page 14] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + +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 executing the CGA generation + algorithm of Section 4 multiple times and by 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 will be explained below, neither is very serious. + + First, the high cost of address generation may prevent hosts that use + a high Sec value from changing their address frequently. This + problem is mitigated because the expensive part of the address + generation may be done in advance or offline, as explained in the + previous section. It should also be noted that the nodes that + benefit most from high Sec values (e.g., DNS servers, routers, and + data servers) usually do not require pseudonymity, and the nodes that + have 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 in the local links that it accesses, it + should generate not only a new address but also a new public key. + With typical local-link technologies, however, 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. + +7.4. Related Protocols + + 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. This means that other + protocols (perhaps even those designed without an 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. + + + +Aura Standards Track [Page 15] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + To prevent the 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 + with even poorly designed protocols that do not 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 to 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 that 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 by 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 the way in which they + have been generated. The name space is essentially unlimited, and + any number of individual values and ranges of at most 256 values can + be allocated. + + + +Aura Standards Track [Page 16] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + 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 + + [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. + + + + + +Aura Standards Track [Page 17] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + [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 + + [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. + + + + +Aura Standards Track [Page 18] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aura Standards Track [Page 19] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + +Appendix A. Example of CGA Generation + + We generate a CGA with Sec=1 from the subnet prefix fe80:: and the + following 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 is initialized to 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 value computed from the above + input are Hash2=436b 9a70 dbfd dbf1 926e 6e66 29c0. This does not + begin with 16*Sec=16 zero bits. Thus, we must increment the modifier + by one and recompute the hash. 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. Thus, 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 value of the above input are + Hash1=fd4a 5bf6 ffb4 ca6c. We form an interface identifier from this + by writing Sec=1 into the three leftmost bits and by setting bits 6 + and 7 (the "u" and "g" bits) to zero. The new interface identifier + is 3c4a:5bf6:ffb4:ca6c. + + + + +Aura Standards Track [Page 20] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + + Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. This is + the new CGA. No address collisions were detected this time. + (Collisions are very rare.) The CGA Parameters data structure + associated with the address is the same as the input to Hash1 above. + +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. + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aura Standards Track [Page 21] + +RFC 3972 Cryptographically Generated Addresses March 2005 + + +Full Copyright Statement + + 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 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. + + + + + + + +Aura Standards Track [Page 22] + |