idnits 2.17.1 draft-ietf-send-cga-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 168 has weird spacing: '...fffffff if Se...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 16, 2004) is 7287 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'AAKMNR02' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'Aura03' is defined on line 803, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-03 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2002' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- No information found for draft-nikander-addr-ownership - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Securing Neighbor Discovery T. Aura 3 Internet-Draft Microsoft Research 4 Expires: October 15, 2004 April 16, 2004 6 Cryptographically Generated Addresses (CGA) 7 draft-ietf-send-cga-06 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on October 15, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document describes a method for binding a public signature key 38 to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. 39 Cryptographically Generated Addresses (CGA) are IPv6 addresses where 40 the interface identifier is generated by computing a cryptographic 41 one-way hash function from a public key and auxiliary parameters. The 42 binding between the public key and the address can be verified by 43 re-computing the hash value and by comparing the hash with the 44 interface identifier. Messages sent from an IPv6 address can be 45 protected by attaching the public key and auxiliary parameters and by 46 signing the message with the corresponding private key. The 47 protection works without a certification authority or other security 48 infrastructure. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. CGA Parameters and Hash Values . . . . . . . . . . . . . . . . 5 55 4. CGA Generation . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. CGA Verification . . . . . . . . . . . . . . . . . . . . . . . 9 57 6. CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 7.1 Security Goals and Limitations . . . . . . . . . . . . . . 12 60 7.2 Hash extension . . . . . . . . . . . . . . . . . . . . . . 13 61 7.3 Privacy Considerations . . . . . . . . . . . . . . . . . . 15 62 7.4 Related protocols . . . . . . . . . . . . . . . . . . . . 15 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 66 9.2 Informative References . . . . . . . . . . . . . . . . . . . 18 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 68 A. Example of CGA Generation . . . . . . . . . . . . . . . . . . 19 69 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 70 Intellectual Property and Copyright Statements . . . . . . . . 21 72 1. Introduction 74 This document specifies a method for securely associating a 75 cryptographic public key with an IPv6 address in the Secure Neighbor 76 Discovery (SEND) protocol [I-D.ietf-send-ndopt]. The basic idea is to 77 generate the interface identifier (i.e., the rightmost 64 bits) of 78 the IPv6 address by computing a cryptographic hash of the public key. 79 The resulting IPv6 address is called a cryptographically generated 80 address (CGA). The corresponding private key can then be used to sign 81 messages sent from the address. 83 This document specifies: 85 o how to generate a CGA from the cryptographic hash of a public key 86 and auxiliary parameters, 88 o how to verify the association between the public key and the CGA, 89 and 91 o how to sign a message that is sent from the CGA, and how to verify 92 the signature. 94 In order to verify the association between the address and the public 95 key, the verifier needs to know the address itself, the public key, 96 and the values of the auxiliary parameters. The verifier can then go 97 on to verify messages signed by the owner of the public key (i.e., 98 the address owner). No additional security infrastructure, such as a 99 public key infrastructure (PKI), certification authorities, or other 100 trusted servers, is needed. 102 It is important to note that because CGAs themselves are not 103 certified, an attacker can create a new CGA from any subnet prefix 104 and its own (or anyone else's) public key. What the attacker cannot 105 do is to take a CGA created by someone else and send signed messages 106 that appear to come from the owner of that address. 108 The address format and the CGA parameter format are defined in 109 Sections 2 and 3. Detailed algorithms for generating addresses and 110 for verifying them are given in Sections 4 and 5, respectively. 111 Section 6 defines the procedures for generating and verifying CGA 112 signatures. The security considerations in Section 7 include 113 limitations of CGA-based security, the reasoning behind the hash 114 extension technique that enables effective hash lengths above the 115 64-bit limit of the interface identifier, the implications of CGAs on 116 privacy, and protection against related-protocol attacks. 118 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 119 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to 120 be interpreted as described in [RFC2119]. 122 2. CGA Format 124 When talking about addresses, this document refers to IPv6 addresses 125 where the leftmost 64 bits of a 128-bit address form the subnet 126 prefix and the rightmost 64 bits of the address form the interface 127 identifier [RFC3513]. We number the bits of the interface identifier 128 starting from bit 0 on the left. 130 A cryptographically generated address (CGA) has a security parameter 131 (Sec), which determines its strength against brute-force attacks. The 132 security parameter is a 3-bit unsigned integer and it is encoded in 133 the three leftmost bits (i.e., bits 0-2) of the interface identifier. 134 This can be written as: 136 Sec = (interface identifier & 0xe000000000000000) >> 61 138 The CGA is associated with a set of parameters, which consist of a 139 public key and auxiliary parameters. Two hash values Hash1 (64 bits) 140 and Hash2 (112 bits) are computed from the parameters. The formats of 141 the public key and auxiliary parameters, and the way to compute the 142 hash values are defined in Section 3. 144 A cryptographically generated address is defined as an IPv6 address 145 that satisfies the following two conditions: 147 o The first hash value, Hash1, equals the interface identifier of 148 the address. Bits 0, 1, 2, 6 and 7 (i.e., the bits that encode the 149 security parameter Sec and the "u" and "g" bits from the standard 150 IPv6 address architecture format of interface identifiers 151 [RFC3513]) are ignored in the comparison. 153 o The 16*Sec leftmost bits of the second hash value, Hash2, are 154 zero. 156 The above definition can be stated in terms of the following two bit 157 masks: 159 Mask1 (64 bits) = 0x1cffffffffffffff 161 Mask2 (112 bits) = 0x0000000000000000000000000000 if Sec=0, 162 0xffff000000000000000000000000 if Sec=1, 163 0xffffffff00000000000000000000 if Sec=2, 164 0xffffffffffff0000000000000000 if Sec=3, 165 0xffffffffffffffff000000000000 if Sec=4, 166 0xffffffffffffffffffff00000000 if Sec=5, 167 0xffffffffffffffffffffffff0000 if Sec=6, and 168 0xffffffffffffffffffffffffffff if Sec=7 170 A cryptographically generated address is an IPv6 address for which 171 the following two equations hold: 173 Hash1 & Mask1 == interface identifier & Mask1 174 Hash2 & Mask2 == 0x0000000000000000000000000000 176 3. CGA Parameters and Hash Values 178 Each CGA is associated with a CGA Parameters data structure, which 179 has the following format: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 + + 186 | | 187 + Modifier (16 octets) + 188 | | 189 + + 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 + Subnet Prefix (8 octets) + 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |Collision Count| | 197 +-+-+-+-+-+-+-+-+ | 198 | | 199 ~ Public Key (variable length) ~ 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 ~ Extension Fields (optional, variable length) ~ 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Modifier 209 This field contains a 128-bit unsigned integer, which can be any 210 value. The modifier is used during CGA generation to implement the 211 hash extension and to enhance privacy by adding randomness to the 212 address. 214 Subnet Prefix 216 This field contains the 64-bit subnet prefix of the CGA. 218 Collision Count 220 This is an 8-bit unsigned integer, which MUST be 0, 1 or 2. The 221 collision count is incremented during CGA generation to recover 222 from an address collision detected by duplicate address detection. 224 Public Key 226 This is a variable length field containing the public key of the 227 address owner. The public key MUST be formatted as a DER-encoded 228 [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo 229 defined in the Internet X.509 certificate profile [RFC3280]. SEND 230 SHOULD use an RSA public/private key pair. When RSA is used, the 231 algorithm identifier MUST be rsaEncryption, which is 232 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted 233 using the RSAPublicKey type as specified in Section 2.3.1 of RFC 234 3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits. 235 Other public key types are undesirable in SEND since they may 236 result in incompatibilities between implementations. The length of 237 this field is determined by the ASN.1 encoding. 239 Extension Fields 241 This is an optional variable-length field, which is not used in 242 the current specification. Future versions of this specification 243 may use this field for additional data items that need to be 244 included in the CGA Parameters data structure. IETF standards 245 action is required to specify the use of the extension fields. 246 Implementations MUST ignore the value of any unrecognized 247 extension fields. 249 The two hash values MUST be computed as follows. The SHA-1 hash 250 algorithm [FIPS.180-1.1995] is applied to the CGA Parameters. When 251 computing Hash1, the input to the SHA-1 algorithm is the CGA 252 Parameters data structure. The 64-bit Hash1 is obtained by taking the 253 leftmost 64 bits of the 160-bit SHA-1 hash value. When computing 254 Hash2, the input is the same CGA Parameters data structure except 255 that the subnet prefix and collision count are set to zero. The 256 112-bit Hash2 is obtained by taking the leftmost 112 bits of the 257 160-bit SHA-1 hash value. Note that the hash values are computed over 258 the entire CGA Parameters data structure, including any unrecognized 259 extension fields. 261 4. CGA Generation 263 The process of generating a new CGA takes three input values: a 264 64-bit subnet prefix, the public key of the address owner as a 265 DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and the 266 security parameter Sec, which is an unsigned 3-bit integer. The cost 267 of generating a new CGA depends exponentially on the security 268 parameter Sec, which can have values from 0 to 7. 270 A CGA and associated parameters SHOULD be generated as follows: 272 1. Set the modifier to a random or pseudorandom 128-bit value. 274 2. Concatenate from left to right the modifier, 9 zero octets, and 275 the encoded public key. Execute the SHA-1 algorithm on the 276 concatenation. Take the 112 leftmost bits of the SHA-1 hash 277 value. The result is Hash2. 279 3. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are 280 all zero (or if Sec=0), continue with step (4). Otherwise, 281 increment the modifier by one and go back to step (2). 283 4. Set the 8-bit collision count to zero. 285 5. Concatenate from left to right the final modifier value, the 286 subnet prefix, the collision count and the encoded public key. 287 Execute the SHA-1 algorithm on the concatenation. Take the 64 288 leftmost bits of the SHA-1 hash value. The result is Hash1. 290 6. Form an interface identifier from Hash1 by writing the value of 291 Sec into the three leftmost bits and by setting bits 6 and 7 292 (i.e., the "u" and "g" bits) both to zero. 294 7. Concatenate the 64-bit subnet prefix and the 64-bit interface 295 identifier to form a 128-bit IPv6 address with the subnet prefix 296 to the left and interface identifier to the right as in a 297 standard IPv6 address [RFC3513]. 299 8. Perform duplicate address detection if required, as per 300 [I-D.ietf-send-ndopt]. If an address collision is detected, 301 increment the collision count by one and go back to step (5). 302 However, after three collisions, stop and report the error. 304 9. Form the CGA Parameters data structure by concatenating from left 305 to right the final modifier value, the subnet prefix, the final 306 collision count value, and the encoded public key. 308 The output of the address generation algorithm is a new CGA and a CGA 309 Parameters data structure. 311 The initial value of the modifier in step (1) SHOULD be chosen 312 randomly in order to make addresses generated from the same public 313 key unlinkable, which enhances privacy (see Section 7.3). The quality 314 of the random number generator does not affect the strength of the 315 binding between the address and the public key. Implementations that 316 have no strong random numbers available MAY use a non-cryptographic 317 pseudo-random number generator that is initialized with the current 318 time of day. 320 For Sec=0, the above algorithm is deterministic and relatively fast. 321 Nodes that implement CGA generation MAY always use the security 322 parameter value Sec=0. If Sec=0, steps (2)-(3) of the generation 323 algorithm can be skipped. 325 For Sec values greater than 0, the above algorithm is not guaranteed 326 to terminate after a certain number of iterations. The brute-force 327 search in steps (2)-(3) takes O(2^(16*Sec)) iterations to complete. 328 It is intentional that generating CGAs with high Sec values is 329 infeasible with current technology. 331 Implementations MAY use optimized or otherwise modified versions of 332 the above algorithm for CGA generation. However, the output of any 333 such modified versions of the algorithm MUST fulfill the following 334 two requirements. First, the resulting CGA and CGA Parameters data 335 structure MUST be formatted as specified in Sections 2-3. Second, the 336 CGA verification procedure defined in Section 5 MUST succeed when 337 invoked on the output of the CGA generation algorithm. It is 338 important to note that some optimizations involve trade-offs between 339 privacy and the cost of address generation. 341 One optimization is particularly important. If the subnet prefix of 342 the address changes but the address owner's public key does not, the 343 old modifier value MAY be reused. If it is reused, the algorithm 344 SHOULD be started from step (4). This optimization avoids repeating 345 the expensive search for an acceptable modifier value but may, in 346 some situations, make it easier for an observer to link two addresses 347 to each other. 349 Note that this document does not specify whether duplicate address 350 detection should be performed and how the detection is done. Step (8) 351 only defines what to do if some form of duplicate address detection 352 is performed and an address collision is detected. 354 Future versions of this specification may specify additional inputs 355 to the CGA generation algorithm, which are concatenated as extension 356 fields to the end of the CGA Parameters data structure. This document 357 does not specify how such data fields are handled during CGA 358 generation. 360 5. CGA Verification 362 CGA verification takes as input an IPv6 address and a CGA Parameters 363 data structure. The CGA Parameters consist of the concatenated 364 modifier, subnet prefix, collision count, public key, and optional 365 extension fields. The verification either succeeds or fails. 367 The CGA MUST be verified with the following steps: 369 1. Check that the collision count in the CGA Parameters data 370 structure is 0, 1 or 2. The CGA verification fails if the 371 collision count is out of the valid range. 373 2. Check that the subnet prefix in the CGA Parameters data structure 374 is equal to the subnet prefix (i.e., the leftmost 64 bits) of the 375 address. The CGA verification fails if the prefix values differ. 377 3. Execute the SHA-1 algorithm on the CGA Parameters data structure. 378 Take the 64 leftmost bits of the SHA-1 hash value. The result is 379 Hash1. 381 4. Compare Hash1 with the interface identifier (i.e., the rightmost 382 64 bits) of the address. Differences in the three leftmost bits 383 and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored. If 384 the 64-bit values differ (other than in the five ignored bits), 385 the CGA verification fails. 387 5. Read the security parameter Sec from the three leftmost bits of 388 the 64-bit interface identifier of the address. (Sec is an 389 unsigned 3-bit integer.) 391 6. Concatenate from left to right the modifier, 9 zero octets, and 392 the public key, and any extension fields that follow the public 393 key in the CGA Parameters data structure. Execute the SHA-1 394 algorithm on the concatenation. Take the 112 leftmost bits of the 395 SHA-1 hash value. The result is Hash2. 397 7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one 398 of them is non-zero, the CGA verification fails. Otherwise, the 399 verification succeeds. (If Sec=0, the CGA verification never 400 fails at this step.) 402 If the verification fails at any step, the execution of the algorithm 403 MUST be stopped immediately. On the other hand, if the verification 404 succeeds, the verifier knows that the public key in the CGA 405 Parameters is the authentic public key of the address owner. The 406 verifier can extract the public key by removing 25 octets from the 407 beginning of the CGA Parameters and by decoding the following 408 SubjectPublicKeyInfo data structure. 410 Note that the values of bits 6 and 7 (the "u" and "g" bits) of the 411 interface identifier are ignored during CGA verification. In the SEND 412 protocol, after the verification succeeds, the verifier SHOULD 413 process all CGAs in the same way regardless of the Sec, modifier and 414 collision count values. In particular, the verifier in the SEND 415 protocol SHOULD NOT have any security policy that differentiates 416 between addresses based on the value of Sec. That way, the address 417 generator is free choose any value of Sec. 419 All nodes that implement CGA verification MUST be able to process all 420 security parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The 421 verification procedure is relatively fast and always requires at most 422 two computations of the SHA-1 hash function. If Sec=0, the 423 verification never fails in steps (6)-(7) and these steps can be 424 skipped. 426 Nodes that implement CGA verification for SEND SHOULD be able to 427 process RSA public keys that have the algorithm identifier 428 rsaEncryption and key length between 384 and 2048 bits. 429 Implementations MAY support longer keys. Future versions of this 430 specification may recommend support for longer keys. 432 Implementations of CGA verification MUST ignore the value of any 433 unrecognized extension fields that follow the public key in the CGA 434 Parameters data structure. However, implementations MUST include any 435 such unrecognized data in the hash input when computing Hash1 in step 436 (3) and Hash2 in step (6) of the CGA verification algorithm. This is 437 important to ensure upward compatibility with future extensions. 439 6. CGA Signatures 441 This section defines the procedures for generating and verifying CGA 442 signatures. In order to sign a message, a node needs the CGA, the 443 associated CGA Parameters data structure, the message, and the 444 private cryptographic key that corresponds to the public key in the 445 CGA Parameters. The node also needs to have a 128-bit type tag for 446 the message from the CGA Message Type name space. 448 To sign a message, a node SHOULD do the following: 450 o Concatenate the 128-bit type tag (in network byte order) and the 451 message with the type tag to the left and the message to the 452 right. The concatenation is the message to be signed in the next 453 step. 455 o Generate the RSA signature using the RSASSA-PKCS1-v1_5 [RFC3447] 456 signature algorithm with the SHA-1 hash algorithm. The inputs to 457 the generation operation are the private key and the concatenation 458 created above. 460 The SEND protocol specification [I-D.ietf-send-ndopt] defines several 461 messages that contain a signature in the Signature Option. The SEND 462 protocol specification also defines a type tag from the CGA Message 463 Type name space. The same type tag is used for all the SEND messages 464 that have the Signature Option. This type tag is an IANA-allocated 465 128 bit integer that has been chosen at random to prevent accidental 466 type collision with messages of other protocols that use the same 467 public key but may or may not use IANA-allocated type tags. 469 The CGA, the CGA Parameters data structure, the message, and the 470 signature are sent to the verifier. The SEND protocol specification 471 defines how these data items are sent in SEND protocol messages. Note 472 that the 128-bit type tag is not included in the SEND protocol 473 messages because the verifier knows its value implicitly from the 474 ICMP message type field in the SEND message. See the SEND 475 specification [I-D.ietf-send-ndopt] for precise information about how 476 SEND handles the type tag. 478 In order to verify a signature, the verifier needs the CGA, the 479 associated CGA Parameters data structure, the message, and the 480 signature. The verifier also needs to have the 128-bit type tag for 481 the message. 483 To verify the signature, a node SHOULD do the following: 485 o Verify the CGA as defined in Section 5. The inputs to the CGA 486 verification are the CGA and the CGA Parameters data structure. 488 o Concatenate the 128-bit type tag and the message with the type tag 489 to the left and the message to the right. The concatenation is the 490 message whose signature is to be verified in the next step. 492 o Verify the RSA signature using the RSASSA-PKCS1-v1_5 [RFC3447] 493 algorithm with the SHA-1 hash algorithm. The inputs to the 494 verification operation are the public key (i.e., the RSAPublicKey 495 structure from the SubjectPublicKeyInfo structure that is a part 496 of the CGA Parameters data structure), the concatenation created 497 above, and the signature. 499 The verifier MUST accept the signature as authentic only if both the 500 CGA verification and the signature verification succeed. 502 7. Security Considerations 504 7.1 Security Goals and Limitations 506 The purpose of CGAs is to prevent stealing and spoofing of existing 507 IPv6 addresses. The public key of the address owner is bound 508 cryptographically to the address. The address owner can use the 509 corresponding private key to assert its ownership of the address and 510 to sign SEND messages sent from the address. 512 It is important to understand that an attacker can create a new 513 address from an arbitrary subnet prefix and its own (or someone 514 else's) public key because CGAs are not certified. What the attacker 515 cannot do is to impersonate somebody else's address. This is because 516 the attacker would have to find a collision of the cryptographic hash 517 value Hash1. (The property of the hash function needed here is called 518 second pre-image resistance [MOV97].) 520 For each valid CGA Parameters data structure, there are 4*(Sec+1) 521 different CGAs that match the value. This is because decrementing the 522 Sec value in the three leftmost bits of the interface identifier does 523 not invalidate the address, and the verifier ignores the values of 524 the "u" and "g" bits. In SEND, this fact does not have any security 525 or implementation implications. 527 Another limitation of CGAs is that there is no mechanism for proving 528 that an address is not a CGA. Thus, an attacker could take someone 529 else's CGA and present it as a non-cryptographically-generated 530 address (e.g., as an RFC-3041 address [RFC3041]). An attacker does 531 not benefit from this because although SEND nodes accept both signed 532 and unsigned messages from every address, they give priority to the 533 information in the signed messages. 535 The minimum RSA key length required for SEND is only 384 bits. So 536 short keys are vulnerable to integer-factoring attacks and cannot be 537 used for strong authentication or secrecy. On the other hand, the 538 cost of factoring 384-bit keys is currently high enough to prevent 539 most denial-of-service attacks. Implementations that initially use 540 short RSA keys SHOULD be prepared switch to longer keys when 541 denial-of-service attacks arising from integer factoring become a 542 problem. 544 The impact of a key compromise on CGAs depends on the application for 545 which they are used. In SEND, it is not a major concern. If the 546 private signature key is compromised because the SEND node itself has 547 been compromised, the attacker does not need to spoof SEND messages 548 from the node. When it is discovered that a node has been 549 compromised, a new signature key and a new CGA SHOULD be generated. 551 On the other hand, if the RSA key is compromised because 552 integer-factoring attacks for the chosen key length have become 553 practical, the key needs to be replaced with a longer one, as 554 explained above. In either case, the address change effectively 555 revokes the old public key. It is not necessary to have any 556 additional key revocation mechanism or to limit the lifetimes of the 557 signature keys. 559 7.2 Hash extension 561 As computers become faster, the 64 bits of the interface identifier 562 will not be sufficient to prevent attackers from searching for hash 563 collisions. It helps somewhat that we include the subnet prefix of 564 the address in the hash input. This prevents the attacker from using 565 a single pre-computed database to attack addresses with different 566 subnet prefixes. The attacker needs to create a separate database for 567 each subnet prefix. Link-local addresses are, however, left 568 vulnerable because the same prefix is used by all IPv6 nodes. 570 In order to prevent the CGA technology from becoming outdated as 571 computers become faster, the hash technique used to generate CGAs 572 must be extended somehow. The chosen extension technique is to 573 increase the cost of both address generation and brute-force attacks 574 by the same parameterized factor while keeping the cost of address 575 use and verification constant. This provides protection also for 576 link-local addresses. Introduction of the hash extension is the main 577 difference between this document and earlier CGA proposals 578 [OR01][Nik01][MC02]. 580 To achieve the effective extension of the hash length, the input to 581 the second hash function Hash2 is modified (by changing the modifier 582 value) until the leftmost 16*Sec bits of the hash value are zero. 583 This increases the cost of address generation approximately by a 584 factor of 2^(16*Sec). It also increases the cost of brute-force 585 attacks by the same factor. That is, the cost of creating a CGA 586 Parameters data structure that binds the attacker's public key with 587 somebody else's address is increased from O(2^59) to 588 O(2^(59+16*Sec)). The address generator may choose the security 589 parameter Sec depending on its own computational capacity, perceived 590 risk of attacks, and the expected lifetime of the address. Currently, 591 Sec values between 0 and 2 are sufficient for most IPv6 nodes. As 592 computers become faster, higher Sec values will slowly become useful. 594 Theoretically, if no hash extension is used (i.e., Sec=0) and a 595 typical attacker is able to tap into N local networks at the same 596 time, an attack against link-local addresses is N times as efficient 597 as an attack against addresses of a specific network. The effect 598 could be countered using a slightly higher Sec value for link-local 599 addresses. When higher Sec values (such that 2^(16*Sec) > N) are used 600 for all addresses, the relative advantage of attacking link-local 601 addresses becomes insignificant. 603 The effectiveness of the hash extension depends on the assumption 604 that the computational capacities of the attacker and the address 605 generator will grow at the same (potentially exponential) rate. This 606 is not necessarily true if the addresses are generated on low-end 607 mobile devices where the main design goals are lower cost and smaller 608 size rather than increased computing power. But there is no reason 609 for doing so. The expensive part of the address generation (steps 610 (1)-(3) of the generation algorithm) may be delegated to a more 611 powerful computer. Moreover, this work can be done in advance or 612 offline, rather than in real time when a new address is needed. 614 In order to make it possible for mobile nodes whose subnet prefix 615 changes frequently to use Sec values greater than 0, we have decided 616 not to include the subnet prefix in the input of Hash2. The result is 617 weaker than if the subnet prefix were included in the input of both 618 hashes. On the other hand, our scheme is at least as strong as using 619 the hash extension technique without including the subnet prefix in 620 either hash. It is also at least as strong as not using the hash 621 extension but including the subnet prefix. This trade-off was made 622 because mobile nodes frequently move to insecure networks where they 623 are at the risk of denial-of-service (DoS) attacks, for example, 624 during the duplicate address detection procedure. 626 In most networks, the goal of Secure Neighbor Discovery and CGA 627 signatures is to prevent denial-of-service attacks. Therefore, it is 628 usually sensible to start by using a low Sec value and to replace 629 addresses with stronger ones only when denial-of-service attacks 630 based on brute-force search become a significant problem. If CGAs 631 were used as a part of a strong authentication or secrecy mechanism, 632 it might be necessary to start with higher Sec values. 634 The collision count value is used to modify the input to Hash1 if 635 there is an address collision. It is important not to allow collision 636 count values higher than 2. First, it is extremely unlikely that 637 three collisions would occur and the reason is certain to be either a 638 configuration or implementation error or a denial-of-service attack. 639 (When the SEND protocol is used, deliberate collisions caused by a 640 DoS attacker are detected and ignored.) Second, an attacker who is 641 doing a brute-force search to match a given CGA can try all different 642 values of collision count without repeating the brute-force search 643 for the modifier value. Thus, if higher values are allowed for the 644 collision count, the hash extension technique becomes less effective 645 in preventing brute force attacks. 647 7.3 Privacy Considerations 649 CGAs can give the same level pseudonymity as the IPv6 address privacy 650 extensions defined in RFC 3041 [RFC3041]. An IP host can generate 651 multiple pseudorandom CGAs by executing the CGA generation algorithm 652 of Section 4 multiple times and using a different random or 653 pseudorandom initial value for the modifier every time. The host 654 should change its address periodically as in [RFC3041]. When privacy 655 protection is needed, the (pseudo)random number generator used in 656 address generation SHOULD be strong enough to produce unpredictable 657 and unlinkable values. Advice on random number generation can be 658 found in [RFC1750]. 660 There are two apparent limitations to this privacy protection. 661 However, as will be explained below, neither limitation is very 662 serious. 664 First, the high cost of address generation may prevent hosts that use 665 a high Sec value from changing their address frequently. This problem 666 is mitigated by the fact that the expensive part of the address 667 generation may be done in advance or offline, as explained in the 668 previous section. It should also be noted that the nodes that benefit 669 most from high Sec values (e.g., DNS servers, routers, and data 670 servers) usually do not require pseudonymity, while the nodes that 671 have high privacy requirements (e.g., client PCs and mobile hosts) 672 are unlikely targets for expensive brute-force DoS attacks and can do 673 with lower Sec values. 675 Second, the public key of the address owner is revealed in the signed 676 SEND messages. This means that if the address owner wants to be 677 pseudonymous towards the nodes in the local links that it accesses, 678 it should not only generate a new address but also a new public key. 679 With typical local-link technologies, however, a node's link-layer 680 address is a unique identifier for the node. As long as the node 681 keeps using the same link-layer address, it makes little sense to 682 ever change the public key for privacy reasons. 684 7.4 Related protocols 686 While this document defines CGAs only for the purposes of Secure 687 Neighbor Discovery, other protocols could be defined elsewhere that 688 use the same addresses and public keys. This raises the possibility 689 of related-protocol attacks where a signed message from one protocol 690 is replayed in another protocol. This means that other protocols 691 (perhaps designed without an intimate knowledge of SEND) could 692 endanger the security of SEND. What makes this threat even more 693 significant is that the attacker could take someone else's public key 694 and create a CGA from it, and then replay signed messages from a 695 protocol that has nothing to do with CGAs or IP addresses. 697 To prevent the related-protocol attacks, a type tag is prepended to 698 every message before signing it. The type-tags are 128-bit randomly 699 chosen values, which prevents accidental type collisions with even 700 poorly designed protocols that do not use any type tags. Moreover, 701 the SEND protocol includes the sender's CGA address in all signed 702 messages. This makes it even more difficult for an attacker to take 703 signed messages from some other context and to replay them as SEND 704 messages. 706 Finally, a strong cautionary note needs to be made about using CGA 707 signatures for other purposes than SEND. First, the other protocols 708 MUST include a type tag and the sender address in all signed messages 709 in the same way as SEND does. Each protocol MUST define its own type 710 tag values as explained in Section 8. Moreover, because of the 711 possibility of related-protocol attacks, the public key MUST be used 712 only for signing and it MUST NOT be used for encryption. Second, the 713 minimum RSA key length of 384 bits may be too short for many 714 applications and the impact of key compromise on the particular 715 protocol needs to be evaluated. Third, CGA-based authorization is 716 particularly suitable for securing neighbor discovery [RFC2461] and 717 duplicate address detection [RFC2462] because these are network-layer 718 signaling protocols where IPv6 addresses are natural endpoint 719 identifiers. In any protocol that uses other identifiers, such as DNS 720 names, CGA signatures alone are not a sufficient security mechanism. 721 There must also be a secure way of mapping the other identifiers to 722 IPv6 addresses. If the goal is not to verify claims about IPv6 723 addresses, CGA signatures are probably not the right solution. 725 8. IANA Considerations 727 This document defines a new CGA Message Type name space for use as 728 type tags in messages that may be signed using CGA signatures. The 729 values in this name space are 128-bit unsigned integers. Values in 730 this name space are allocated on a First Come First Served basis 731 [RFC2434]. IANA assigns new 128-bit values directly without a review. 733 The requester SHOULD generate the new values with a strong 734 random-number generator. Continuous ranges of at most 256 values can 735 be requested provided that the 120 most significant bits of the 736 values have been generated with a strong random-number generator. 738 IANA does not generate random values for the requester. IANA 739 allocates requested values without verifying the way in which they 740 have been generated. The name space is essentially unlimited and any 741 number of individual values and ranges of at most 256 values can be 742 allocated. 744 CGA Message Type values for private use MAY be generated with a 745 strong random-number generator without IANA allocation. 747 This document does not define any new values in any name space. 749 9. References 751 9.1 Normative References 753 [I-D.ietf-send-ndopt] 754 Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. 755 Nikander, "SEcure Neighbor Discovery (SEND)", 756 draft-ietf-send-ndopt-03 (work in progress), January 2003. 758 [RFC3279] Bassham, L., Polk, W. and R. Housley, "Algorithms and 759 Identifiers for the Internet X.509 Public Key 760 Infrastructure Certificate and Certificate Revocation List 761 (CRL) Profile", RFC 3279, April 2002. 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 766 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 767 (IPv6) Addressing Architecture", RFC 3513, April 2003. 769 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 770 X.509 Public Key Infrastructure Certificate and 771 Certificate Revocation List (CRL) Profile", RFC 3280, 772 April 2002. 774 [ITU.X690.2002] 775 International Telecommunications Union, "Information 776 Technology - ASN.1 encoding rules: Specification of Basic 777 Encoding Rules (BER), Canonical Encoding Rules (CER) and 778 Distinguished Encoding Rules (DER)", ITU-T Recommendation 779 X.690, July 2002. 781 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 782 Standards (PKCS) #1: RSA Cryptography Specifications 783 Version 2.1", RFC 3447, February 2003. 785 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 786 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 787 October 1998. 789 [FIPS.180-1.1995] 790 National Institute of Standards and Technology, "Secure 791 Hash Standard", Federal Information Processing Standards 792 Publication FIPS PUB 180-1, April 1995, . 795 9.2 Informative References 797 [AAKMNR02] 798 Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. 799 and M. Roe, "Securing IPv6 neighbor discovery and router 800 discovery", ACM Workshop on Wireless Security (WiSe 2002), 801 Atlanta, GA USA , September 2002. 803 [Aura03] Aura, T., "Cryptographically Generated Addresses (CGA)", 804 6th Information Security Conference (ISC'03), Bristol, UK 805 , October 2003. 807 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 808 Recommendations for Security", RFC 1750, December 1994. 810 [MOV97] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook 811 of Applied Cryptography", CRC Press , 1997. 813 [MC02] Montenegro, G. and C. Castelluccia, "Statistically unique 814 and cryptographically verifiable identifiers and 815 addresses", ISOC Symposium on Network and Distributed 816 System Security (NDSS 2002), San Diego, CA USA , February 817 2002. 819 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 820 Stateless Address Autoconfiguration in IPv6", RFC 3041, 821 January 2001. 823 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 824 Discovery for IP Version 6 (IPv6)", RFC 2461, December 825 1998. 827 [Nik01] Nikander, P., "A scaleable architecture for IPv6 address 828 ownership", draft-nikander-addr-ownership-00 (work in 829 progress), March 2001. 831 [OR01] O'Shea, G. and M. Roe, "Child-proof authentication for 832 MIPv6 (CAM)", ACM Computer Communications Review 31(2), 833 April 2001. 835 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 836 Autoconfiguration", RFC 2462, December 1998. 838 Author's Address 840 Tuomas Aura 841 Microsoft Research 842 Roger Needham Building 843 7 JJ Thomson Avenue 844 Cambridge CB3 0FB 845 United Kingdom 847 Phone: +44 1223 479708 848 EMail: tuomaura@microsoft.com 850 Appendix A. Example of CGA Generation 852 We generate a CGA with Sec=1 from the subnet prefix fe80:: and the 853 following public key: 855 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 856 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 857 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 858 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001 860 The modifier is initialized to a random value 89a8 a8b2 e858 d8b8 861 f263 3f44 d2d4 ce9a. The input to Hash2 is: 863 89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a 0000 0000 0000 0000 00 864 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 865 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 866 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 867 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001 869 The 112 first bits of the SHA-1 hash value computed from the above 870 input are Hash2=436b 9a70 dbfd dbf1 926e 6e66 29c0. This does not 871 begin with 16*Sec=16 zero bits. Thus, we must increment the modifier 872 by one and recompute the hash. The new input to Hash2 is: 874 89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b 0000 0000 0000 0000 00 875 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 876 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 877 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 878 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001 880 The new hash value is Hash2=0000 01ca 680b 8388 8d09 12df fcce. The 881 16 leftmost bits of Hash2 are all zero. Thus, we found a suitable 882 modifier. (We were very lucky to find it so soon.) 884 The input to Hash1 is: 886 89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b fe80 0000 0000 0000 00 887 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 888 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 889 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 890 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001 892 The 64 first bits of the SHA-1 hash value of the above input are 893 Hash1=fd4a 5bf6 ffb4 ca6c. We form an interface identifier from this 894 by writing Sec=1 into the three leftmost bits and by setting bits 6 895 and 7 (the "u" and "g" bits) to zero. The new interface identifier is 896 3c4a:5bf6:ffb4:ca6c. 898 Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. This is 899 the new CGA. No address collisions were detected this time. 900 (Collisions are very rare.) The CGA Parameters data structure 901 associated with the address is the same as the input to Hash1 above. 903 Appendix B. Acknowledgements 905 The author gratefully acknowledges the contributions of Jari Arkko, 906 Francis Dupont, Pasi Eronen, Christian Huitema, James Kempf, Pekka 907 Nikander, Michael Roe, Dave Thaler, and other participants of the 908 SEND working group. 910 Intellectual Property Statement 912 The IETF takes no position regarding the validity or scope of any 913 intellectual property or other rights that might be claimed to 914 pertain to the implementation or use of the technology described in 915 this document or the extent to which any license under such rights 916 might or might not be available; neither does it represent that it 917 has made any effort to identify any such rights. Information on the 918 IETF's procedures with respect to rights in standards-track and 919 standards-related documentation can be found in BCP-11. Copies of 920 claims of rights made available for publication and any assurances of 921 licenses to be made available, or the result of an attempt made to 922 obtain a general license or permission for the use of such 923 proprietary rights by implementors or users of this specification can 924 be obtained from the IETF Secretariat. 926 The IETF invites any interested party to bring to its attention any 927 copyrights, patents or patent applications, or other proprietary 928 rights which may cover technology that may be required to practice 929 this standard. Please address the information to the IETF Executive 930 Director. 932 The IETF has been notified of intellectual property rights claimed in 933 regard to some or all of the specification contained in this 934 document. For more information consult the online list of claimed 935 rights. 937 Full Copyright Statement 939 Copyright (C) The Internet Society (2004). All Rights Reserved. 941 This document and translations of it may be copied and furnished to 942 others, and derivative works that comment on or otherwise explain it 943 or assist in its implementation may be prepared, copied, published 944 and distributed, in whole or in part, without restriction of any 945 kind, provided that the above copyright notice and this paragraph are 946 included on all such copies and derivative works. However, this 947 document itself may not be modified in any way, such as by removing 948 the copyright notice or references to the Internet Society or other 949 Internet organizations, except as needed for the purpose of 950 developing Internet standards in which case the procedures for 951 copyrights defined in the Internet Standards process must be 952 followed, or as required to translate it into languages other than 953 English. 955 The limited permissions granted above are perpetual and will not be 956 revoked by the Internet Society or its successors or assignees. 958 This document and the information contained herein is provided on an 959 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 960 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 961 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 962 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 963 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 965 Acknowledgment 967 Funding for the RFC Editor function is currently provided by the 968 Internet Society.