IETF Securing Neighbor Discovery WG Tuomas Aura INTERNET DRAFT Microsoft Research Expires December 2003 June 2003 Cryptographically Generated Addresses (CGA) draft-ietf-send-cga-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 13, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a method for binding a public signature key to an IPv6 address in Secure Neighbor Discovery (SEND). Cryptographically Generated Addresses (CGA) are IPv6 addresses where the interface identifier is generated by computing a cryptographic one-way hash function from the address owner's 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. SEND protocol messages are protected with an Authentication Header (AH) that contains the public key and the auxiliary parameters and is signed with the corresponding private key. The protection works without a certification authority or other security infrastructure. Table of Contents Aura Expires December 13, 2003 [Page 1] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 Status of This Memo...............................................1 Copyright Notice..................................................1 Abstract..........................................................1 Table of Contents.................................................1 1. Introduction...................................................2 2. The CGA Address Format.........................................3 3. The CGA Parameters and the Hash Values.........................4 4. CGA Generation.................................................5 5. CGA Verification...............................................6 6. The CGA Authorization Mechanism for SEND.......................8 6.1 Sending SEND Messages........................................8 6.2 Receiving SEND messages......................................9 7. Security Considerations........................................9 7.1 Security Goals and Limitations...............................9 7.2 Hash extension..............................................10 7.3 Privacy Considerations......................................12 8. IANA Considerations...........................................13 Acknowledgments..................................................13 Intellectual Property Statement..................................13 Normative References.............................................13 Informative References...........................................14 Appendix A. Example of CGA Generation..........................14 Appendix B. Changes since draft-aura-cga-pre01.................14 Author's Address.................................................15 Intellectual Property Statement..................................15 Full Copyright Statement.........................................15 1. Introduction This document specifies a method for securely associating a public key with an IPv6 address in the secure neighbor discovery (SEND) protocol [AKSZ03]. The basic idea is to generate the interface identifier (i.e. rightmost 64 bits) of the IPv6 address by computing a cryptographic hash of the public key. This kind of IPv6 addresses are called cryptographically generated addresses (CGA). The corresponding private key can then be used to sign SEND messages. More specifically, this document specifies - how to create CGA addresses from the cryptographic hash of a public key and auxiliary parameters, - how to transfer the public key and the auxiliary parameters in a signed SEND message, and - how to verify the association between the public key and the IPv6 address. Aura Expires December 13, 2003 [Page 2] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 In order 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. No additional security infrastructure, such as a public key infrastructure (PKI), certification authorities, or other trusted servers, is needed. 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 a method for authenticating SEND messages where the source address is a CGA address. The security considerations in Section 7 include limitations of CGA-based authentication, the reasoning behind the hash extension technique that enables effective hash lengths above the 64-bit limit of the interface identifier, and the implications CGA addresses on privacy. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [Bra97]. 2. The CGA Address Format When talking about addresses, this document refers to IPv6 addresses where 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. [HD03] A cryptographically generated address (CGA) has a security parameter (Sec), which determines its strength against brute-force attacks. The security parameter is a 3-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: Sec = (interface identifier & 0xe000000000000000) >> 61 The CGA address is associated with a set of parameters, which consist of a public key and auxiliary parameters. Two hash values Hash1 and Hash2 (64 and 112 bits, respectively) are computed from the parameters. The formats of the public key and auxiliary parameters and the inputs to the hash functions are defined in Section 3. A cryptographically generated address (CGA) is defined as an IPv6 address where the 16*Sec leftmost bits of the second hash value Hash2 are zero, and the rightmost 64 bits of the first hash value Hash1 equal the interface identifier of the address. The three Aura Expires December 13, 2003 [Page 3] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 leftmost bits of the address, which encode the security parameter Sec, and the "u" and "g" bits are ignored in the comparison. The "u" and "g" bits (i.e. bits 6 and 7 of the interface identifier) must both be zero. The above definition can be stated in terms of the following two bit masks: Mask1 (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 Mask2 (64 bits) = 0xfcfffffffffffff8 Mask3 (64 bits) = 0xfffffffffffffff8 A cryptographically generated address is an IPv6 address for which the following two equations hold: Hash1 & Mask2 == interface identifier & Mask3 Hash2 & Mask1 == 0x0000000000000000000000000000 3. The CGA Parameters and the Hash Values Each CGA address is associated with a DER-encoded [ITU02] ASN.1 data item of the type CGAParameters: CGAParameters ::= SEQUENCE { auxParameters CGAAuxParameters, publicKey SubjectPublicKeyInfo } CGAAuxParameters ::= SEQUENCE { modifier OCTET STRING (SIZE 16), subnetPrefix OCTET STRING (SIZE 8), collisionCount INTEGER (0..2) } The publicKey data item contains the address owner's public key. The ASN.1 type SubjectPublicKeyInfo is defined in the Internet X.509 certificate profile [HFPS02]. In addition to the public key, there are three auxiliary parameters: o a 16-octet modifier, which can get any value Aura Expires December 13, 2003 [Page 4] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 o the 8-octet subnetPrefix, which is equal to the subnet prefix of the CGA address, and o collisionCount, which can get values 0, 1 and 2. The two hash values are computed with the SHA-1 hash algorithm [NIS95] from the DER-encoded CGAParameters data item. When computing Hash1, the input to the SHA-1 algorithm is simply the DER-encoding. The 64-bit Hash1 is obtained by taking the leftmost 64 bits of then 160-bit SHA-1 hash value. When computing Hash2, the value of the subnetPrefix data item is set to 8 zero octets and the value of the collisionCount data item is set to 0. The 112-bit Hash1 is obtained by taking the leftmost 112 bits of the 160-bit SHA-1 hash value. 4. CGA Generation The process of generating a new CGA address takes three input values: a 64-bit subnet prefix, the public key of the address owner, and the security parameter Sec, which is an unsigned 3-bit integer. The result is a new CGA address and the associated parameters. The cost of generating a new CGA address depends on the security parameter Sec, which gets values from 0 to 7. A CGA address and associated CGA parameters SHOULD be generated as follows: (1) Create an ASN.1 data item of type CGAParameters. Set the publicKey data value to the address owner's public key. Set the modifier data value to 16 random octets. Set the subnetPrefix data value to 8 zero octets. Set the collisionCount data value to zero. (2) DER-encode the CGAParameters data value. Execute the SHA-1 algorithm on the DER-encoded CGAParameters data value. 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 the step (4). Otherwise, increment the modifier data value (as if its content octets were a 128-bit integer) and go back to step (2). (4) Set the 8-octet subnetPrefix data value in the encoded CGAParameters data item to the given subnet prefix. Aura Expires December 13, 2003 [Page 5] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 (5) Execute the SHA-1 algorithm on the new DER-encoded CGAParameters data value. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1. (6) Form an EUI-64 interface identifier by setting the "u" and "g" bits in Hash1 both to 0 and the three leftmost bits of the address to the value Sec. (7) Concatenate the 64-bit subnet prefix and the EUI-64 interface identifier to form a 128-bit IPv6 address. (8) If an address collision is detected, increment the collisionCount data value in the DER-encoded CGAParameters data item and go back to step (5). However, after three collisions, stop and report the error. In order to avoid trying the same modifier values repeatedly, it is RECOMMENDED to that the initial modifier value in step (1) is chosen randomly and that the modifier is incremented in step (3) as if it were an unsigned 128-bit integer. When incrementing the modifier, the octet order can be chosen arbitrarily and overflows can be ignored. The quality of the random number generator is not important as long as the same values are not repeated frequently. However, if privacy enhancement (see Section 7.3) is required, the random numbers should be unpredictable and unlinkable. For Sec=0, the above algorithm is deterministic and relatively fast. Nodes that implement CGA generation MAY set the security parameter Sec to always 0. In that case, steps (2)-(3) of the generation algorithm can be skipped. For Sec values greater than 0, 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. Implementations SHOULD take into account the fact that generating CGA addresses with high Sec values will take considerable time and that generating addresses with the highest Sec values is infeasible with today's technology. 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 avoids repeating the expensive search for an acceptable modifier value. 5. CGA Verification CGA verification takes two inputs: an IPv6 address and a DER- encoded CGAParameters data item. The verification either succeeds or fails. Aura Expires December 13, 2003 [Page 6] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 The CGA MUST be verified with the following steps: (1) Check that the "g" and "u" bits in the interface identifier are both zero. If either bit is non-zero, the CGA verification fails. (2) 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.) (3) Decode the DER-encoded CGAParameters data item. Check that the subnetPrefix data value is equal to the subnet prefix (i.e. leftmost 64 bits) of the address. Check that the collisionCount value is 0, 1 or 2. The CGA verification fails if the decoding of the CGA parameters fails, if the subnetPrefix value does not match the address, or if the collisionCount value is out of range. (4) Execute the SHA-1 algorithm on the DER-encoded CGAParameters data value. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1. (5) Compare Hash1 with the interface identifier (i.e. the rightmost 64 bits) of the address. Differences in the "g" and "u" bits and in the three leftmost bits are ignored. If the 64-bit values differ (other than in the five ignored bits), the CGA verification fails. (6) Set the subnetPrefix data value in the DER-encoded CGAParameters data item to 8 zero octets and the collisionCount data value to 0. (7) Execute the SHA-1 algorithm on the new DER-encoded CGAParameters data value. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2. (8) Compare the 16*Sec leftmost bits of Hash2 with zero. If any one of them is non-zero, the CGA verification fails. Otherwise, the verification succeeds. (If Sec=0, the CGA verification never fails at this step.) If the verification succeeds, the verifier knows that the publicKey field in the CGAParameters data value is the authentic public key of the address owner. 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 a Aura Expires December 13, 2003 [Page 7] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 constant amount of computation. If Sec=0, the verification never fails in steps (6)-(8) and these steps MAY be skipped. After the verification succeeds or fails, the verifier SHOULD discard the Sec, modifier and collisionCount values and not use them for any further purpose. In particular, the verifier should set the minSec value in the inbound AH_RSA_Sig security association to zero (see [AKSZ03] Section 7.1.3). Future extensions of this specification may define situations where a it is acceptable for the verifier to set higher minSec values. 6. The CGA Authorization Mechanism for SEND Nodes that use Secure Neighbor Discovery (SEND) protocol MUST process outbound and inbound SEND messages as specified in [AKSZ03]. This section gives additional guidance on using the CGA authorization mechanism in these messages. 6.1 Sending SEND Messages sNodes that use the Secure Neighbor Discovery (SEND) protocol and use CGA addresses MUST use the format of the CGA addresses as described in Section 2, SHOULD generate the addresses as described in Section 4. The public key used for the address generation MUST have the object identifier sha1WithRSAEncryption [JK03]. The RSA public key MUST be at least 1024 bits long. A node that has a CGA address MAY use the CGA authorization mechanism when it sends secure Neighbor Solicitations (NS), Neighbor Advertisements (NA), Router Solicitations (RS) and Router Advertisements (RA) where the IP source address is a CGA address and the source link-layer address option is present in the message. Note that the node MAY use trusted-root authorization mechanism instead or in addition to the CGA authorization mechanism authentication. The mechanism to be used is determined by the node's IPSec configuration. When sending a secure NA, NS, RA or RS message, the node MUST protect the message with an IPSec Authentication Header (AH) that uses the AH_RSA_Sig transform defined in [AKSZ03]. Within the AH, the contents of the Key Information field are represented as ASN.1 DER-encoded data item of the following type: SendKeyInformation ::= SEQUENCE { cgaParameters CGAParameters OPTIONAL, signerInfo SubjectPublicKeyInfo OPTIONAL } Aura Expires December 13, 2003 [Page 8] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 (The normative definition of the type SendKeyInformation is in [AKSZ03].) When the CGA authorization mechanism is used in a SEND message, the cgaParameters field in SendKeyInformation MUST be present and its value MUST be the same CGAParameters data value that was used for generating the IP source address of the SEND message. The signature in the AH MUST be verifiable with the public key that is sent in the CGAParameters. 6.2 Receiving SEND messages Received SEND messages MUST be processed as specified in Section 7.1.6 of [AKSZ03]. If the security association requires the verification of the CGA property, the receiver must verify the MUST verify the source address of the packet as described in Section 5. The inputs for the algorithm are the source address of the packet and the contents of the CGAParameters structure from the Key Information field. If the CGA verification is successful, the node goes on to verify the signature in the AH as defined in [AKSZ03]. On the other hand, if the CGA verification fails, the recipient MUST stop processing the SEND message and ignore its contents. 7. Security Considerations 7.1 Security Goals and Limitations The purpose of CGA addresses is to prevent stealing and spoofing of IPv6 addresses in the secure neighbor discovery protocol. 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 of the address and to sign SEND messages sent from the address. It is important to understand that that attacker can create a new address from an arbitrary subnet prefix and its own public key. What the attacker cannot do is to 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 or weak collision resistance.) For each valid CGAParameters data value, there are Sec different CGA addresses 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. In SEND, this fact does not have any security or implementation implications. Aura Expires December 13, 2003 [Page 9] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 Another limitation of CGA addresses is that there is no mechanism for proving that an address is not a CGA address. Thus, an attacker could take someone else's CGA address and present it as a non-CGA address (e.g. as an RFC-3041 address). To avoid being tricked, every node must either accept neighbor discovery messages with CGA- based authentication or unauthenticated ones, but not both. This effectively means that secure and insecure nodes on the same network cannot talk directly to each other. Nodes can, however, be configured to use different subnet prefixes for CGA and non-CGA addresses. Finally, a cautionary note should be made about using CGA-based authentication for other purposes than SEND. CGA-based authentication is particularly suitable for securing neighbor discovery [NN98] and duplicate address detection [TN98] because these are network-layer signaling protocols where IPv6 addresses are natural endpoint identifiers. In any protocol that aims to protect higher-layer data, CGA-based authentication alone is not sufficient but there must also be a secure mechanism for mapping higher-layer identifiers, such as DNS names, to IP addresses. 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 subnet prefix is used by all IPv6 nodes. In the long term, some kind of hash extension technique must be used to counter the effect of faster computers. Otherwise, the CGA technology could become outdated after 5-20 years. The idea in this document 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 provides protection also 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 Hash2 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 Aura Expires December 13, 2003 [Page 10] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 attacks by the same factor. That is, the cost of creating a certificate 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, 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-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 of the assumption that the computational capacity of the attacker and the address generator will grow and the same (potentially exponential) rate. This is clearly not true if the addresses are generated on low-end mobile devices. But there is no reason for doing so. The expensive part of the address generation (steps (2)-(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. In order to make it possible for mobile nodes whose subnet prefix changes frequently to use Sec values greater than 0, we have decided not to include the subnet prefix in the input of Hash2. The result is weaker than 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- based authentication 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 CGA address were used as a part of a strong authentication or secrecy mechanisms, it would be necessary to start with higher Sec values.) Aura Expires December 13, 2003 [Page 11] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 The collisionCount value is used to modify the input to Hash1 if there is an address collision. It is important not to allow collisionCount 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, the deliberate collisions caused by a DoS attacker are detected and ignored.) Second, an attacker who is doing a brute-force search to match a given CGA address can try all different values of collisionCount without repeating the brute-force search for the modifier value. Thus, the more different values are allowed for collisionCount, the less effective the hash-extension technique is in preventing brute-force attacks. 7.3 Privacy Considerations CGA addresses can give the same level pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [ND01]. An IP host can generate multiple pseudorandom CGA addresses by executing the CGA generation algorithm of Section 4 multiple times and by using every time a different random or pseudorandom initial value for the modifier. The host should change its address periodically as in [ND01]. When privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values. There are two apparent limitations to this privacy protection. However, as we will explain below, neither limitation 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 by the fact that 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, while the nodes that have high privacy requirements (e.g. client PCs and mobile hosts) are unlikely targets for expensive brute-force attacks and can do with lower Sec values. Second, the public key of the address owner is revealed in the authenticated SEND messages. This means that if the address owner wants to be pseudonymous towards the nodes in the local links that it accesses, it should not only generate a new address but also a new public key. With typical local-link technologies, however, a node's link-layer address makes it possible for others to correlate its appearances of the local link. As long as the node keeps using Aura Expires December 13, 2003 [Page 12] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 the same link-layer address, it makes little sense to ever change the public key for privacy reasons. 8. IANA Considerations No new IANA-allocated values are defined in this document. Acknowledgments Many of the ideas in this draft were influenced by Michael Roe, Christian Huitema and Pekka Nikander. Jari Arkko, Pasi Eronen and other participants in the IETF working group made many helpful comments. Intellectual Property Statement Several IPR claims have been made about the technology described in this document. Normative References [AKSZ03] Jari Arkko, James Kempf, Bill Sommerfeld, and Brian Zill. Secure neighbor discovery (SEND). Internet-Draft draft-ietf- send-ipsec-01.txt, IETF Securing Neighbor Discovery Working Group, June 2003. Work in progress. [Bra97] Scott Bradner. Key words for use in RFCs to indicate requirement levels. RFC 2119, IETF Network Working Group, March 1997. [HD03] Robert M. Hinden and Stephen E. Deering. IP version 6 addressing architecture. RFC 3513, IETF Network Working Group, April 2003. [HFPS02] Russell Housley, Warwick Ford, Tim Polk, and David Solo. Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile. RFC 3280, IETF Network Working Group, April 2002. [ITU02] International Telecommunication Union. ITU-T recommendation X.690, information technology -- ASN.1 encoding rules: Specification of basic encoding rules (BER), canonical encoding rules (CER) and distinguished encoding rules (DER), July 2002. Also appeared as ISO/IEC International Standard 8825-1. [JK03] Jakob Jonsson and Burt Kaliski. Public-key cryptography standards (PKCS) #1: RSA cryptography specifications version 2.1. RFC 3447, IETF Network Working Group, February 2003. Aura Expires December 13, 2003 [Page 13] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 [NIS95] Secure hash standard. Federal Information Processing Standards Publication FIPS PUB 180-1, National Institute of Standards and Technology, Gaithersburg, MD USA, April 1995. Informative References [AAK+02] Jari Arkko, Tuomas Aura, James Kempf, Vesa-Matti M„ntyl„, Pekka Nikander, and Michael Roe. Securing IPv6 neighbor discovery and router discovery. In Proc. 2002 ACM Workshop on Wireless Security (WiSe), pages 77-86, Atlanta, GA USA, September 2002. ACM Press. [MC02] Gabriel Montenegro and Claude Castelluccia. Statistically unique and cryptographically verifiable identifiers and addresses. In Proc. ISOC Symposium on Network and Distributed System Security (NDSS 2002), San Diego, February 2002. [ND01] Thomas Narten and Richard Draves. Privacy extensions for stateless address autoconfiguration in IPv6. RFC 3041, IETF Network Working Group, January 2001. [NN98] Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor discovery for IP version 6 (IPv6). RFC 2461, IETF Network Working Group, December 1998. [Nik01] Pekka Nikander. A scaleable architecture for IPv6 address ownership. Internet-draft, March 2001. Work in Progress. [OR01] Greg O'Shea and Michael Roe. Child-proof authentication for MIPv6 (CAM). ACM Computer Communications Review, 31(2), April 2001. [TN98] Susan Thomson and Thomas Narten. IPv6 stateless address autoconfiguration. RFC 2462, IETF Network Working Group, December 1998. Appendix A. Example of CGA Generation TBW Appendix B. Changes since draft-aura-cga-pre01 This appendix is intended only for the readers who reviewed a preliminary version of this draft titled draft-aura-cga-pre01. o The number of zero bits in hash 2 is 16*Sec (was 12*Sec), length of Hash2 is 112 bits (was 84 bits), and the length of modifier 16 octets (was 12 octets). Makes coding easier and extends the maximal hash length. Aura Expires December 13, 2003 [Page 14] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 o Sec is now encoded in the three leftmost bits of the 64-bit interface identifier. Earlier, it was encoded in the three rightmost bits. Using the rightmost bits would distort the distribution of solicited-node multicast addresses. o Changed the order of the publicKey and auxParameters fields in CGAParameters. This makes decoding without an ASN.1 compiler easier because the fixed-length fields come first. o sha1WithRSAEncryption is now the only allowed signature algorithm. Minimum key length is 1024 bits. The minimum key length makes the decoding of CGAParameters easier. Author's Address Tuomas Aura Microsoft Research 7 J J Thomson Avenue Cambridge, CB3 0FB United Kingdom Phone: +44 1223 479708 Email: tuomaura@microsoft.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Aura Expires December 13, 2003 [Page 15] INTERNET-DRAFT Cryptographically Generated Addresses (CGA) June 2003 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Aura Expires December 13, 2003 [Page 16]