Network Working Group Jari Arkko INTERNET-DRAFT Pekka Nikander Category: Informational Vesa-Matti Mantyla Ericsson June 2002 Securing IPv6 Neighbor Discovery Using Cryptographically Generated Addresses (CGAs) 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 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 inapproporiate 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html The distribution of this memo is unlimited. It is filed as , and expires December 24, 2002. Please send comments to the authors. Abstract IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. The original ND specifications called for the use of IPsec for protecting the ND messages. However, in this particular application the use of IPsec may not always be feasible, mainly due to difficulties in key management. If not secured, ND protocol is vulnerable to various attacks. This document specifies a lightweight security solution for ND that does not rely on pre- configuration or trusted third parties. The presented solution uses Cryptographically Generated Addresses. Conventions used in this document 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 [RFC 2119]. Arkko et al. Informational [Page 1] Internet Draft Secure ND with CGAs June, 2002 Table of contents 1. Introduction...................................................2 2. Definitions....................................................3 3. Neighbor Discovery.............................................3 4. Approaches for Securing Neighbor Discovery.....................4 5. Cryptogaphically Generated Addresses...........................6 5.1. Generation................................................6 5.2. Signatures................................................7 5.3. Verification .............................................7 5.4. Algorithms................................................8 6. Securing Neighbor Discovery with CGA...........................8 6.1. Duplicate Address Detection...............................8 6.2. Address Resolution........................................9 6.3. Neighbor Unreachability Detection.........................9 7. Securing Router Discovery with CGA.............................9 7.1. Router Discovery..........................................9 7.2. Redirect.................................................10 8. Option Formats................................................11 8.1. Public Key Option........................................11 8.2. Signature Option.........................................12 9. Security Considerations.......................................12 10. Acknowledgments...............................................13 11. References....................................................13 11.1. Normative References....................................13 11.2. Non-normative References................................13 12. IPR Considerations............................................14 13. Authors' Address..............................................14 1. Introduction IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [ND98]. Nodes on the same link use the ND protocol to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. The ND protocol is used both by hosts and routers. Its functions include Router Discovery (RD), Address Auto- configuration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection. Section 4 gives a description of different approaches for securing the ND protocol. This shows that the specified IPsec method isn't always applicable. In Sections 6 to 8 we present a new, lightweight solution for ND security. Our approach is based on the use of Cryptographically Generated Addresses (CGAs) [CAM01]. The CGA method provides a proof of address ownership, i.e., it provides assurance that the node we are talking to is indeed the one that came up with the very address. In our solution, there is no need for an external key management infrastructure. All the used keys can be self-generated, and can be presented without external credentials. Section 5 briefly introduces the CGA method. Arkko et al. Informational [Page 2] Internet Draft Secure ND with CGAs June, 2002 Our requirements call for secure ND signaling to be possible both in private networks as well as in public access networks. In the public access networks we can't trust all parties to behave in an appropriate manner. At the moment this specification considers only the case of networks that are fully protected with our secure ND approach. That is, we do not yet deal with the problem of securing some ND messages with our approach while allow some other messages to be secured with the traditional IPsec approach or even be left unsecured. 2. Definitions Cryptographically Generated Addresses (CGAs) - A technique where the address of the node is cryptographically generated from the public key of the node and some other parameters using a one-way hash function [CAM01]. Also called SUCD Identities in [SUCV]. Internet Control Message Protocol version 6 (ICMPv6) - The IPv6 control signaling protocol. Neighbor Discovery is a part of ICMPv6. Neighbor Discovery (ND) - The IPv6 Neighbor Discovery protocol[ND98]. 3. Neighbor Discovery The main functions of IPv6 Neighbor Discovery are as follows: - Neighbor Unreachability Detection (NUD) is used for tracking the reachability of neighbors, both local destinations and routers [ND98, Section 7.3]. - Duplicate Address Detection (DAD) is used for preventing address collisions [ND98, AUTOCONF98]. A node that intends to assign a new address to one of its interfaces runs first the DAD procedure to verify that other nodes are not using the same address. - Address Resolution is similar to IPv4 ARP [ARP82]. The Address Resolution function resolves a node's IPv6 address to the corresponding link-layer address for nodes on the link [ND98, Section 7.2]. Address Resolution is used for hosts and routers alike. - Address Autoconfiguration is used for automatically assigning addresses to a host [AUTOCONF98]. This allows hosts to operate without configuration related to IP connectivity. The Address Autoconfiguration mechanism is stateless, where the hosts use prefix information delivered to them during Router Discovery to create addresses, and then test these addresses for uniqueness using the DAD procedure. A stateful mechanism, DHCPv6, provides additional Autoconfiguration features. - The Redirection function is used for automatically redirecting hosts to an alternate router [ND98, Section 8]. It is similar to the ICMPv4 Redirect message [POS81]. Arkko et al. Informational [Page 3] Internet Draft Secure ND with CGAs June, 2002 - The Router Discovery function allows IPv6 hosts to discover the local routers on an attached link [ND98, Section 6]. The Neighbor Discovery messages follow the ICMPv6 message format and ICMPv6 types from 133 to 137. The IPv6 Next Header value for ICMPv6 is 58. The actual Neighbor Discovery message includes an ND message header consisting of ICMPv6 header and ND message-specific data, and zero or more ND options: <------------ND Message-----------------> *-----------------------------------------------------------* | IPv6 Header | ICMPv6 | ND message- | ND Message | | Next Header = 58 | Header | specific | Options | | (ICMPv6) | | data | | *-----------------------------------------------------------* <--ND Message header--> The ND message options are formatted in the Type-Length-Value format. All IPv6 ND protocol functions are realized using the following messages: ICMPv6 Type Message ------------------------------------ 133 Router Solicitation (RS) 134 Router Advertisement (RA) 135 Neighbor Solicitation (NS) 136 Neighbor Advertisement (NA) 137 Redirect The functions of the ND protocol are realized using these messages as follows: - Router Discovery uses the RS and RA messages. - Duplicate Address Detection uses the NS and NA messages. - Address Autoconfiguration uses the NS, NA, RS, and RA messages. - Address Resolution uses the NS and NA messages. - Neighbor Unreachability Detection uses the NS and NA messages. - Redirect uses the Redirect message. All functions but Address Auto-configuration are explained in RFC 2461. The Address Auto-configuration is presented in RFC 2462. In Section 8 we define two new ND message options that are used in our security solution. 4. Approaches for Securing Neighbor Discovery When ND is not secured, attackers can cause, for instance, the following types of problems [Ark01, Ark02]: - Making hosts adopt bogus prefixes. This leads to Denial-of- Service. - Making hosts adopt bogus default routers. This leads to Denial-of- Service and can also be used in an attempt to place the attacker as a Man-in-the-Middle for all communications. Arkko et al. Informational [Page 4] Internet Draft Secure ND with CGAs June, 2002 - Sending spoofed answers to DAD queries in an attempt to prevent a host from acquiring any address. - Sending spoofed Address Resolution messages in an attempt to cause Denial-of-Service or to place the attacker as a Man-in-the-Middle between the neighbors. - Sending spoofed NUD messages. This can be used to make the neighbor believe the node is reachable when it is not. - Sending spoofed Redirect messages, again in an attempt to cause Denial-of-Service or to place the attacker as a Man-in-the-Middle. The ND protocol ignores packets received from off-link nodes by verifying that the Hop Limit field contains the value 255. Since every forwarding router reduces this value by one, an ND packet containing the Hop Limit value of 255 must originate from a neighboring IPv6 node. However, this does not protect against malicious neighbors. It is possible to authenticate the ND protocol packet exchanges using the IPSec Authentication Header, if a suitable SA exists. This is the approach specified in the original specification [ND98]. However, three different types of problems exist with this approach: - Running an automatic keying protocol such as IKE would involve sending IP traffic, which may be impossible in the initial stages of some the ND procedures. For instance, we can't send IKE UDP packets before we have an address. Also, the node needs to discover the link layer address of the neighbor. This is a chicken-and-egg problem, since getting an address or finding the link layer address of the peer would require running ND, which in turn would require the security associations to be already in place. - Manual SAs can be configured, but as [Ark01] points out this may lead to a large number of SAs. The definition of IPsec requires a different SA for every IP address that is used as a destination. - According to RFC 2461 [ND98], the ND protocol "provides no mechanism to determine, which neighbors are authorized to send a particular type of message", e.g a Router Advertisement. The current set of IPsec policy selectors do not allow us to define which nodes are allowed to send which particular ND messages. - IPsec in general can prove that the peers are among the intended users of the link. However, we also need to authorize the contents of the messages. For instance, even if a particular node is authorized to send Neighbor Advertisements, it is usually authorized to send them only on its own behalf. Manually configured SAs with security policy entries that limit the use of source address can in some cases handle this, but it isn't expected that trusted third parties and certificate infrastructures can keep up with the right IP address identities of all users at all times. Arkko et al. Informational [Page 5] Internet Draft Secure ND with CGAs June, 2002 Due to the above, the use of IPsec in securing ND for public access networks is hard, and it isn't clear that attacks can be avoided even when IPsec is used. Various new approaches to securing ND have been designed. One of these approaches is the Address Based Keys method which is discussed in [ABK02]. 5. Cryptographically Generated Addresses The purpose of the CGA method is to ensure that only the node that "owns" an address has the right to make statements about this address, e.g., for the purpose of address resolution. In the CGA method a node first generates a private-public key pair. The public key and some other parameters are used to generate the CGA address. The private key is used for signing signaling messages related to this address. The public key has to be distributed to the receiving node(s) for the signature verification to be possible. It isn't necessary to protect the transfer of the public key. The following text gives a more detailed description of the calculations the nodes have to perform when using the CGA. 5.1. Generation An IPv6 address is composed of two parts: Address = Routing Prefix | Interface ID In the CGA scheme, the Route Prefix is derived in a usual manner, whereas the Interface ID of the node is created using the following procedure: 1. Select the security parameter Sec = 0, 1 , 2, 3. 2. Calculate Hash = HASH("CGA" | Sec | Routing Prefix | PK | Random), where HASH A one-way hash algorithm. PK The Public Key of the node. "CGA" A three octet long string consisting of the ASCII characters 'C', 'G', and 'A'. Sec One octet security parameter that can be used to tune the amount of work needed to create CGA addresses. The rationale for Sec is discussed more in depth in [Ark02]. Routing Prefix The 64 routing prefix. Random A 64 bit long random number. Arkko et al. Informational [Page 6] Internet Draft Secure ND with CGAs June, 2002 3. Select 64+20 x Sec rightmost bits of the hash output and compare the 20 x Sec leftmost bits to zero. If not zero, proceed to generate a new Random value and go back to Step 2. 4. Concatenate the 64-bit Routing Prefix and the rightmost 64 bits of the Hash to obtain the Address. 5. Set the group and the universal bits [ADD98] to 1 and the two rightmost bits to Sec. 6. Perform Duplicate Address Detection. If collision is detected, proceed to generate a new Random value and return to Step 2. After three collisions, stop and report error. Note that the Sec parameter is included in both in the address and in the hash input. The indication to use CGA-based addresses is encoded by setting the group and universal bits to 1. 5.2. Signatures SIG = SIGALG(HASH(Contents),SK), Where SIGALG A public key signature algorithm. Contents Some statement relating to the address in question. SK Secret Key of the node. For ND messages, the Contents is formed from the following parts: 1. The IPv6 header with the exception of the destination address field. (The purpose of omitting the destination address field is to avoid the CPU intensive signature generation when responding with the same message to different nodes.) 2. The ICMPv6/ND message with the exception of the Signature ND option. (The rest of the IPv6 message, e.g. the IPv6 Payload length or the ICMPv6 Length field are not modified as a result of omitting this part.) 5.3. Verification In order to verify that a given address has been formed using CGA, the receiver performs the following steps: 1. Check that the group and the universal bits are 1. If not, the verification process fails. 2. Retrieve the Routing Prefix from the highest 64 bits of the address, Sec from the lowest 2 bits of the address, and PK and Random from an option accompanying the ND message. If the necessary option is not present in the message, the verification process fails. 3. Calculate the hash as defined in Section 5.1, set the group and universal bits, set the two lowest bits to Sec, and compare to the 64 lowest bits in the given address. If the values are not the same, the verification process fails. 4. The process succeeds. Arkko et al. Informational [Page 7] Internet Draft Secure ND with CGAs June, 2002 In order to verify a given statement about a particular address, the following process is used: 1. Check that the address in the source field of the message has been formed using CGA, as explained above. If this fails, the verification process fails. 2. Construct a Contents string as described in Section 5.2. 3. Verify that the signature found in the Signature ND option has been produced using the private key corresponding to the public key found from the Public Key ND option. If this fails, the verification process fails. 4. The process succeeds. 5.4. Algorithms In this specification, the one-way hash algorithm used in CGA generation and signature calculation is the SHA1 algorithm [SHA1]. As the public key algorithm we use the RSA algorithm [RSA78]. 6. Securing Neighbor Discovery The following text describes the procedures involved in securing ND with CGA. The method affects the transmitting and reception of Neighbor Advertisement (NA) messages. All nodes MUST acquire a CGA-based address on all interfaces they communicate according to the procedure presented in Section 5.1. All nodes follow the rules defined below when transmitting NA messages: 1. The node MUST use a CGA-based address as the source address in the IPv6 header that carries the ND message. 2. The node MUST attach the Public Key ND option to the NA message with the same parameters that were used in the construction of address in the source address field. 3. The node MUST attach the Signature ND option to the NA message, and calculates this signature as specified in Section 5.2. All nodes follow the rules defined below when receiving NA messages: 1. The NA message MUST have a Public Key and Signature ND options. Messages that do not have these options MUST be silently discarded. 2. The receiver MUST verify the signature as described in Section 5.3. Messages that fail this verification MUST be silently discarded. In the following we discuss how the above procedures affect the security of ND functions. We will also describe function-specific rules for the treatment of the NA messages. 6.1. Duplicate Address Detection To the extent that CGA is secure, only the owner of the address can reply with a verifiable signature to a DAD query. This prevents other parties from sending replies in an attempt to prevent the host from getting an address. Arkko et al. Informational [Page 8] Internet Draft Secure ND with CGAs June, 2002 After receiving an NS message, in this case the DAD query, and detecting an address collision, a node uses the above procedures for sending the NA message. A node that receives the DAD reply, i.e. the NA message, uses the above procedures for receiving the NA message. If no valid replies are received, the tentative address is set to the VALID state. If the verification succeeded, the tentative address of the host is set to the DISABLED state. 6.2. Address Resolution Here, the CGA method is used to assure that only the real owner of the address can produce a valid response. The rules for sending and receiving the NA message have again been described earlier. Note that the link-layer address ND option is also protected with the signature, preventing a Man-in-the-Middle from replacing another link-layer address to a legitimate reply. 6.3. Neighbor Unreachability Detection Here the CGA method makes sure that attackers cannot claim that a node is reachable when it is not. For the procedure to process NA messages, see the beginning of Section 6. After a successful verification of the NA message, the node is marked as REACHABLE by the host. 7. Securing Router Discovery For Router Discovery, we use CGA to ensure that a given message comes from the claimed IP address. However, this does not offer any information about the ability and willingness of the router to act as a router, or that the advertised network prefixes are correct. We use a heuristic process to verify these properties. All routers MUST acquire a CGA-based address on all interfaces they communicate according to the procedure presented in Section 5.1. The router MUST use the same CGA-based address for both Neighbor Discovery and Router Discovery purposes. 7.1. Router Discovery All routers follow the rules defined below when transmitting RA messages: 1. The router MUST use a CGA-based address as the source address in the IPv6 header that carries the RA message. 2. The router MUST attach the Public Key ND option to the RA message with the same parameters that were used in the construction of address in the source address field. 3. The router MUST attach the Signature ND option to the RA message, and calculates this signature as specified in Section 5.2. All hosts follow the rules defined below when receiving RA messages: Arkko et al. Informational [Page 9] Internet Draft Secure ND with CGAs June, 2002 1. The RA message MUST have a Public Key and Signature ND options. Messages that do not have these options MUST be silently discarded. 2. The receiver MUST verify the signature as described in Section 5.3. Messages that fail this verification MUST be silently discarded. Still, even if the signature is verified correctly the host MUST check that the node claiming to be a router acts as a real router. We propose the following heuristic method: - Each entry in the default router list of the host is marked either as an UNTESTED, TESTED, or FAILED router. All new entries start from the UNTESTED state. - All communications from a host SHOULD use a router in the TESTED state, unless there are only UNTESTED ones available. FAILED routers SHOULD NOT be used for communications. - When communicating to a non-local destination through the designated router, the host SHOULD keep track of the upper layer forward progress, in the same manner as is used in avoiding NUD [ND98, Section 7.3]. If such forward progress is being made, the router in question SHOULD be marked as TESTED. - If no forward progress is being made, the host MAY attempt to send an ICMPv6 Echo request to verify that the router is working. Such requests MUST be addressed to a non-local destination known to the host, and MUST be rate-limited in the usual manner. A reply moves the router to the TESTED state. - If no forward progress is being made, and no replies have been seen, the router SHOULD be marked as FAILED. - Routers that have not been used by the host for a period of 120 seconds SHOULD be marked as UNTESTED. - Routers in the FAILED state may be periodically tested with the ICMPv6 Echo request. A similar process SHOULD be applied to test the prefixes advertised by the router. Note that this heuristic process is inherently weak in the sense that a smart attacker could spoof response messages to unprotected communications or to the Echo requests. For this purpose it is strongly recommended that the hosts use only IPsec or TLS-protected communications as an indication of forward progress. This requires, however, that the hosts share a security association with another node in the Internet. Public web servers with TLS support and a certificate from a trusted root server are one possibility for arranging this security association in an easy manner. 7.2. Redirect Routers use CGA to prove that the Redirect message comes from the right router. All routers follow the rules defined below when transmitting Redirect messages: 1. The router MUST use a CGA-based address as the source address in the IPv6 header that carries the Redirect message. Arkko et al. Informational [Page 10] Internet Draft Secure ND with CGAs June, 2002 2. The router MUST attach the Public Key ND option to the Redirect message with the same parameters that were used in the construction of address in the source address field. 3. The router MUST attach the Signature ND option to the Redirect message, and calculates this signature as specified in Section 5.2. All hosts follow the rules defined below when receiving Redirect messages: 1. The Redirect message MUST have a Public Key and Signature ND options. Messages that do not have these options MUST be silently discarded. 2. The receiver MUST verify the signature as described in Section 5.3. Messages that fail this verification MUST be silently discarded. 3. The receiver MUST verify that the Redirect message comes from an IP address to which the host may have earlier sent the packet that the Redirect message now partially returns. That is, the source address of the Redirect message must be the default router for traffic sent to the destination of the returned packet. If this is not the case, the message MUST be silently discarded. Step 3 prevents a bogus router from sending a Redirect message when the host is not using the bogus router as a default router. 8. Option Formats 8.1. Public Key Option The Public Key Option carries a public key of the node. This option follows the format presented in [ND98]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Algorithm ID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Random + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm ID2 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Public Key (N bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where, Type An IANA assigned 8 bit identifier TBD for the option type. Length An 8 bit unsigned integer indicating the option length (type + length fields) in units of 8 octets. Algorithm ID1 An IANA assigned 16 bit identifier for Arkko et al. Informational [Page 11] Internet Draft Secure ND with CGAs June, 2002 the signature algorithm. The currently defined values are: 1 RSA Random A 64 bit random number used in the creation of the address from the public key. Algorithm ID2 An IANA assigned 16 bit identifier for the hash algorithm. The currently defined values are: 1 SHA1 Public Key An N bit field carrying the public key, zero-padded to nearest 8 byte units. The public key is in the format implied by Algorithm ID1. 8.2. Signature Option The Signature Option carries a digital signature calculated using the private key of the node. This option follows the format presented in [ND98]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Digital Signature (N bits) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where, Type An IANA assigned 8 bit identifier TBD for the option type. Length An 8 bit unsigned integer indicating the option length (type + length fields) in units of 8 octets. Digital Signature An N bit field carrying the digital signature, zero-padded to nearest 8 byte units. The signature is calculated using the algorithm implied by Algorithm ID1 in the public key option, and is also in the format implied by this Algorithm ID1. 9. Security Considerations The CGA method assures that the received messages are coming from the owner of the address. However, this method does not eliminate all security vulnerabilities related to the ND functions. CGA prevents spoofed answers to DAD queries. An attacker may still be able to prevent valid responses or requests from reaching the intended recipient. As a result both participants are forced to believe that no address collision exists, when there in fact is. Arkko et al. Informational [Page 12] Internet Draft Secure ND with CGAs June, 2002 Within Address Resolution and NUD functions CGA can be used to prevent spoofed responses. However, it is still possible to prevent the Address Resolution and NUD from completing for a given address. For the NUD, this means that a node is claimed to be unreachable, when it really is not. Hosts can use CGA to show that the Redirect messages come from their current router. Still, we cannot say anything about the other router mentioned in the Redirect message. It is not clear if this is necessary, however. (If necessary, we could cross-certify routers without involving hosts.) Within the Router Discovery functionality the CGA method ensures that we are communicating with the same router all the time, and prevents spoofing of the link-layer address of the router. But it does not help to verify that the router is connected to the Internet or that it is authorized to advertise a specific route prefix. A proper verification of these properties will not be possible without involving a trusted third party. However, we propose a heuristic method to test these properties in Section 7.1. 10. Acknowledgments The authors would like to thank James Kempf, Gabriel Montenegro, Erik Nordmark, Tuomas Aura and Mike Roe for interesting discussions in this problem space. 11. References 11.1. Normative References [ND98] Narten, T., Nordmark, E., and Simpson, W., "Neighbor discovery for IP Version 6 (IPv6)", RFC 2461, December, 1998. [AUTOCONF98] Thomson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [ADD98] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 2372, July 1998. [RSA78] Rivest, R., Shamir, A., Adleman, L. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, 21 (2), pp. 120-126, February 1978. [SHA1] Eastlake, D., Jones, P., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. 11.2. Non-Normative References [ABK02] Kempf, J., Gentry, G., Silverberg, A., "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", Internet Draft (work in progress), February 2002. [Ark01] Arkko, J., Nikander, P., Kivinen, T., Rossi, M., "Manual SA Configuration for IPv6 link Local Messages", Internet Draft (work in progress), January 2001. Arkko et al. Informational [Page 13] Internet Draft Secure ND with CGAs June, 2002 [Ark02] Arkko, J., Aura, T., Kempf, T., Mantyla, V.-M., Nikander, P., Roe, M. "Securing IPv6 Neighbor Discovery". Submitted for publication, 2002. [ARP82] Plummer, D. C., "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1982. [CAM01] O'Shea, G., Roe, M., "Child-proof Authentication for MIPv6 (CAM), Computer Communications Review", April 2001. [POS81] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981. [SUCV] Montenegro, G., Castelluccia, C., "SUCV Identifiers and Addresses", Internet Draft (work in progress), November 2001. 12. IPR Considerations The presented protocol uses public keys and hashes to prove address ownership. Ericsson's IPR may apply on such methods. The Ericsson policy on IPR issues can be checked from the Ericsson General IPR statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General. 13. Authors' Addresses Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland EMail: jari.arkko@ericsson.com Pekka Nikander Oy LM Ericsson Ab 02420 Jorvas Finland EMail: pekka.nikander@nomadiclab.com Vesa-Matti Mantyla Oy LM Ericsson Ab Tutkijantie 2C 90570 Oulu Finland EMail: vesa-matti.mantyla@ericsson.fi Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Arkko et al. Informational [Page 14] Internet Draft Secure ND with CGAs June, 2002 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph areincluded 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. Arkko et al. Informational [Page 15]