Network Working Group J. Laganier Internet-Draft ENS Lyon / Sun Microsystems, Inc. Expires: December 29, 2003 G. Montenegro Sun Microsystems, Inc. June 30, 2003 Using IKE with IPv6 Cryptographically Generated Address draft-laganier-ike-ipv6-cga-01 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 29, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes IKE peer authentication via IPv6 Cryptographically Generated Addresses (CGA). This technique can be used to provide 'Opportunistic IPsec' between IPv6 nodes or security gateways. These CGA's have been proposed to solve several security issues in the absence of any centralized trusted security infrastructure. Laganier & Montenegro Expires December 29, 2003 [Page 1] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 2. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Node Configuration and Requirements . . . . . . . . . . . . . 6 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Transport Mode Opportunistic IPsec . . . . . . . . . . . . . . 8 5.2 Tunnel Mode Opportunistic IPsec . . . . . . . . . . . . . . . 9 6. ISAKMP Payload usage and requirements . . . . . . . . . . . . 11 6.1 Identification Payload . . . . . . . . . . . . . . . . . . . . 11 6.2 Certificate Payload . . . . . . . . . . . . . . . . . . . . . 11 6.3 Certificate Request Payload . . . . . . . . . . . . . . . . . 11 6.4 Authentication Payload . . . . . . . . . . . . . . . . . . . . 12 6.5 Traffic Selector Payload . . . . . . . . . . . . . . . . . . . 12 7. IKE_AUTH and CREATE_CHILD_SA validation . . . . . . . . . . . 13 7.1 Opportunistic Transport Mode . . . . . . . . . . . . . . . . . 13 7.2 Opportunistic Tunnel Mode . . . . . . . . . . . . . . . . . . 13 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Intellectual Property Rights Considerations . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . . . 18 Informative References . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 Laganier & Montenegro Expires December 29, 2003 [Page 2] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 1. Introduction and Problem Statement This document describes how to use IKE with IPv6 Cryptographically Generated Address (CGA). This technique only requires slight modifications and can be used by one or both peers to achieve 'Opportunistic IPsec' ([4]). One use of CGA is address proof-of-ownership, but it can also be used with authorization certificates (e.g. SPKI, Keynote2) to enable a flexible authorization framework. CGA's have been proposed to solve several security issues in the absence of any centralized trusted security infrastructure, for example, securing Binding Updates in Mobile IPv6, securing Neighbor Discovery for IPv6, and securing Group Membership in Multicast and Anycast communications. Until now, Opportunistic IPsec deployment has been severely limited because it constrains IP nodes to have either a pre-shared key or a common trusted root (e.g., a PKI infrastructure). Thus, the lack of a global, Internet-wide, trusted infrastructure has precluded a straightforward application of IPsec between any two previously unknown nodes. The impossibility of always having the choice of obtaining a security association by leveraging a centralized infrastructure has led to this type of cryptographic techniques commonly known as CGA or SUCV to be applied to IPsec. This note is organized as follows: we will first describe related work and some usage scenarios for a CGA-enabled peer authentication within an IKE exchange, then we will enumerate requirements for those ISAKMP payloads that need it, and finally, describe precisely how to validate the IKE_AUTH_SA and CREATE_CHILD_SA steps of such an IKE exchange. Laganier & Montenegro Expires December 29, 2003 [Page 3] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 2. Related work CGA usage has lacked generality as it has been applied either within specific frameworks like Mobile IP ([5], [6]) or using its own custom protocol, Statistically Unique and Cryptographically Verifiable protocol (sucvP) [5]. Lately, a proposal using Just Fast Keying (JFK) has been put forth ([9]). Nevertheless, we believe that a full-blown key exchange protocol is redundant. Moreover, because the design, implementation and debugging of a new security protocol is especially costly and error-prone, we think that it is not worth "reinventing the wheel". From the point of view of implementation effort, the fact that this approach only requires the addition of stand-alone CGA validation routines into existing IKE daemons (e.g. racoon, isakmpd, pluto, etc) is another considerable advantage. Accordingly, this note presents an overview of how to use the Internet Key Exchange protocol [1] while one or both peers authenticate themselves via CGA proof-of-ownership. This document details the slight modifications needed. Additionally, it aims at capturing the current thinking about how to achieve proof-of- ownership in IKE via CGA in a standard manner, thus preventing subsequent conflicting definitions. Laganier & Montenegro Expires December 29, 2003 [Page 4] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 3. Terminology Cryptographically Generated Address (CGA): An adress which is obtained using cryptographic material as input parameter to a hash function. Crypto-Based Identifier (CBID): An identifier which is obtained using cryptographic material as input parameter to a hash function. CGA enabled Node: An IPv6 node that has one CGA configured as its IPv6 address. Opportunistic IPsec (OIPsec): Opportunistic IPsec denotes the use of the IPsec family of protocols between previously unknown nodes implementing an Opportunistic Security Policy. This includes running IKE between those peers to establish an IPsec Security Association (ESP and/or AH in either Transport or Tunnel Mode). Opportunistic Security Gateway (OSGW): An opportunistic gateway is an IPsec security gateway which applies a tunnel mode Opportunistic Security Policy (OSP) to traffic originating from or sinking at its "local network". It has a CBID instead of a CGA, and holds SPKI authorization certificates issued by the CGA's it protects with OIPsec. Opportunistic Security Policy (OSP): An Opportunistic Security Policy is a Security Policy that specifies that traffic towards any outbound destination (i.e., ::0/0) SHOULD be protected by IPsec, either transport mode or tunnel mode (transport mode for securing end-to-end traffic between two nodes and tunnel mode for securing traffic between two OSGW's, while in transit in the public internet). Laganier & Montenegro Expires December 29, 2003 [Page 5] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 4. Node Configuration and Requirements Each node needs to prove address ownership of their CGA. Similarly, OSGW's only need to prove identifier ownership of their CBID. Thus, they generates a public-private key pair, PK and SK, respectively. The nodes then use PK to obtain and configure a CGA and the OSGW's a CBID as specified in [5]: CBID = SHA1_128 ( PK ) CGA = NetworkPrefix | SHA1_64 ( PK ) Where PK can be a PK certificate (see below) Those nodes that want to prove that they own their CGA should use it as their so-called IKE "peer" address while sending IKE packets. OSGW's can use any of their addresses, but they need to have an SPKI authorization certificate issued on their behalf by each CGA holder: CGA_1 => CBID : OSGW CGA_2 => CBID : OSGW (...) CGA_n => CBID : OSGW Meaning that each CGA_i (0CGA mapping to the network prefix in which the CGA resides, the certificate is concatenated with this network prefix before hashing, as per [6]. This alleviate the problem of pre- computation attacks on the CGA key-space (2^62). Thus, one is not able to re-use the results of a previous brute-force search attacks on CGA. CBID = SHA1_128 ( X509{PK} ) Laganier & Montenegro Expires December 29, 2003 [Page 6] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 CGA = NetworkPrefix | SHA1_64 ( X509Cert{PK} | NetworkPrefix) Notice that the CBID generated from a certificate is indeed very similar to the FullID proposal [7]. Another technique to generate CGA's with an increased security level of 112 bits (instead of the 62 bits provided in the IID) has been described for SEND purposes [8]. Laganier & Montenegro Expires December 29, 2003 [Page 7] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 5. Usage Scenarios CGA authentication within an IKE exchange can be applied in several different usage scenarios. The following sections describe some of these scenarios while emphasizing on easiness of Opportunistic Security Policy configuration. Opportunistic IPsec bootstraps an IPsec Security Association between two previously unknown nodes. Some schemes have been proposed to achieve this goal: FreeS/WAN Opportunistic IPsec uses the standard IKE protocol and DNS queries to retrieve IKE peers' public keys. While these schemes certainly allow to bootstrap such an SA, we argue that it is not convenient to rely on upper layer infrastructure (e.g., DNS) to secure the network layer. This causes cyclic dependencies that ends up in a chicken-and-egg problem: DNS is carried over {TCP|UDP}/IP and a consistent Opportunistic security policy should require that this traffic be protected as well, thus requiring Opportunistic negotiation to secure needed KEY RR lookups. On the other hand, a CGA-based scheme achieves true independence because the security gateways can discover each other and verify authorization by relying solely on IP infrastructure. We propose one CGA Opportunistic IPsec scheme per IPsec mode (transport and tunnel). 5.1 Transport Mode Opportunistic IPsec Transport Mode Opportunistic IPsec secures end-to-end communications between any two previously unknown CGA-enabled nodes implementing an OSP. For instance, let's assume that Alice initially wants to send a data packet to Bob. Transport Mode OSP requires protection of this data packet. As no trust relationship exists between Alice and Bob prior to this, they needs to establish a Transport Mode IPsec Security Association. [Alice]<=i=p=s=e=c==t=r=a=n=s=p=o=r=t=>[Bob] Bootstrapping an IPsec SA between two CGA-enabled nodes is straightforward: the two peers merely prove ownership of their CGA's while performing the IKE exchange, and configure negotiated IPsec SA's. A typical Transport Mode OSP policy should look like that: INBOUND: ::0/0[ike] -> cga_addr/128[any] udp bypass ::0/0[any] -> cga_addr/128[ike] udp bypass Laganier & Montenegro Expires December 29, 2003 [Page 8] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 ::0/0[any] -> cga_addr/128[any] any require (ipsec/ah/esp/ transport) OUTBOUND: cga_addr/128[any] -> ::0/0[ike] udp bypass cga_addr/128[ike] -> ::0/0[any] udp bypass cga_addr/128[any] -> ::0/0[any] any require (ipsec/ah/esp/ transport) 5.2 Tunnel Mode Opportunistic IPsec This section uses the model and mechanism described in ([9]) applied with IKE. Tunnel Mode Opportunistic IPsec is used to secure communications between two CGA-enabled nodes (Alice and Bob), while this traffic is in transit between Alice and Bob's OSGW's (GW_i denotes the IKE initiator and GW_r the responder). [Alice]<---[GW_i]<=i=p=s=e=c==t=u=n=n=e=l=>[GW_r]--->[Bob] Bootstrapping a tunnel mode IPsec SA between two CGA-enabled nodes is not as straightforward as it is for transport mode, because (1) the responder OSGW GW_r needs to be discovered by the initiator OSGW GW_i, and (2) both initiator and responder OSGW need to be authorized by the source and destination CGA's respectively of the data packet that initially triggered this exchange. Thus, a Tunnel Mode OSP always contains an entry with the unspecified IPv6 address (i.e., ::0) as a placeholder for both tunnel endpoints (local and remote). If we denote by NetworkPrefix/pflen the network prefix and associated length where Alice resides, a typical Tunnel Mode OSP should look like that on the interface of GW_i attached to the Internet: INBOUND: ::0/0[ike] -> GW_i/128[any] udp bypass ::0/0[any] -> GW_i/128[ike] udp bypass ::0/0[any] -> NetworkPrefix/pflen[any] any require (ipsec/ah/esp/ tunnel=::0->::0) OUTBOUND: GW_i/128[any] -> ::0/0[ike] udp bypass Laganier & Montenegro Expires December 29, 2003 [Page 9] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 GW_i/128[ike] -> ::0/0[any] udp bypass NetworkPrefix/pflen[any] -> ::0/0[any] any require (ipsec/ah/esp/ tunnel=::0->::0) GW_i can discover GW_r by initiating the IKE exchange towards a per network prefix anycast address allocated by IANA. Others discovery means are also possible, like those described in [4] that makes use of DNS queries to retrieve the OSGW associated with a given host. OSGW authorization imply the verification of authorization (a.k.a. delegation) certificates with the TS_i and TS_r payloads. Each GW holds a Crypto-Based Identifier (CBID) and each node that want its traffic to be protected by this gateway uses a CGA. The gateway holds one SPKI authorization certificate per node it protects. For instance, Alice should provide its OSGW GW_i with an authorization certificate issued by her CGA authorizing the CBID of GW_i to act as an OSGW: Alice_CGA =>GW_i_CBID : OSGW Bob should similarly provide its OSGW GW_r with a certificate issued by his CGA authorizing the CBID of GW_r to to act as an OSGW: Bob_CGA =>GW_r_CBID : OSGW When a packet from Alice to Bob triggers an IKE exchange, the two OSGW's GW_i and GW_r merely prove ownership of their CBID's and exchange authorization certificates issued by Alice and Bob's CGAs authorizing their respective OSGW's to act as such. Following that, they negotiate and configure a pair of bidirectional SA's between the two gateways: GW_i -> GW_r spi=0x... ipsec tunnel ah/esp keys=... GW_i -> GW_r spi=0x... ipsec tunnel ah/esp keys=... And they finally add two news SPD entries specifying that subsequent communications between Alice and Bob's CGA's require IPsec protection: Alice_CGA/128[any] -> Bob_CGA/128[any] any require (ipsec/ah/esp/ tunnel=GW_i->GW_r) Bob_CGA/128[any] -> Alice_CGA/128[any] any require (ipsec/ah/esp/ tunnel=GW_i->GW_r) Laganier & Montenegro Expires December 29, 2003 [Page 10] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 6. ISAKMP Payload usage and requirements A peer implementing OIPsec has to use ISAKMP payloads in a specific manner. The following subsections describe usage and requirements of some of the ISAKMP payloads while performing IKE_AUTH and CREATE_CHILD_SA exchanges. 6.1 Identification Payload The Identification (ID) Payload of IKE contains the name of the entity to be authenticated with the Authentication (AUTH) Payload. When using CGA, the name of the node is its CGA. Though CGA are IPv6 Addresses as well, a peer embedding its CGA within the ID payload under the type ID_IPV6_ADDR would not trigger any verification of the PK-CGA binding on the other side. Hence, we believe that a new ID type is needed to explicitly state the cryptographic nature of a CGA and require verification of the binding. Thus, a peer wanting to prove CGA ownership MUST use an ID payload of type ID_IPV6_CGADDR containing its CGA. The value of type ID_IPV6_CGADDR is initially assigned out of the range 249-255 reserved for "private use amongst cooperating systems", as per [2]. If justified, a subsequent, more official assignment will imply IANA involvement. As per CGA, CBID might require a new ID type as well. This is however very similar to the already proposed FullID type [7]. 6.2 Certificate Payload The Certificate (CERT) Payload provide a means to transport certificates within IKE packets. When performing CGA ownership exchange, certificates should be used to transmit to the correspondent the public key used to generate the CGA. When performing a tunnel mode CREATE_CHILD_SA exchange, authorization certificates issued by the data packet source and destination CGA's should be exchanged. Though several types of certificates are specified in [1], we only use those that contains either a public key for CGA proof-of-ownership (i.e., PKCS7_WRAPP_X509_CERT, PGP_CERT, DNS_SIGNED_KEY, X509_CERT_SIGNATURE and SPKI_CERT) or an authorization certificates (i.e., SPKI_CERT). A peer wanting to prove CGA ownership MUST send a CERT payload that contains the public key used when generating its CGA. An OSGW's wanting to prove that it is authorized to act as an OSGW for a given CGA MUST send a CERT payload containing a SPKI authorization certificates issued by this CGA. 6.3 Certificate Request Payload The Certificate Request (CERTREQ) Payload is used by a peer to request preferred certificates to its correspondent. A preference is Laganier & Montenegro Expires December 29, 2003 [Page 11] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 the type of certificate requested as well as an acceptable certificate authority for this type. A peer can include multiples preferences using several CERTREQ payload. For CGA, certificates used would usually be self-signed, though this does not preclude one to generate its CGA using a CA-signed certificate. 6.4 Authentication Payload The Authentication (AUTH) Payload contains data used to authenticate the entity named in the ID payload (i.e., the CGA owner). Since CGA are generated using public key cryptography, the AUTH payload has to contain a digital signature of the message computed using the public key contained in the CERT payload. Currently specified digital signature algorithms includes RSA and DSA, but this scheme could be used with any public key cryptographic algorithm. 6.5 Traffic Selector Payload The Traffic Selector (TS) Payload contains headers used to identify IP packet flows which need IPsec processing. In the case of CGA OIPsec, those flows will fly between two CGA's. Hence we require that the TS payloads used contains CGA's. This imply that the TS Type is set to TS_IPV6_ADDR. Those CGA's will subsequently need to be validated against X509 and possibly SPKI certificates contained in the CERT payloads exchanged. Laganier & Montenegro Expires December 29, 2003 [Page 12] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 7. IKE_AUTH and CREATE_CHILD_SA validation [1] does not mandate that two peers exchanging keys use the same means of authenticating themselves. Available means of authentication are Digital Signatures, Public Key Encryption and Pre- shared Secret. It is explicitly stated that end-points are not required to use the same means of authenticating themselves. One could use pre-shared secret, while the other could use a digital signature. This note does not conflict with that, allowing one or both entities to prove CGA ownership, thus allowing one to possibly use another means of authenticating itself. CGA-aware IKE peers wanting to exchange traffic with CGA enabled nodes (e.g. nodes or OSGW's) MUST verify CGA ownership. CGA-aware IKE implementation should thus be modified to handle CGA verification, which is very similar to how they currently handle self-signed certificates. Apart from verifying the self-signed certificate, the implementation MUST verify that the public key contained in the certificate (or the certificate itself) generate the address used in the identity payload as previously detailed (ID_IPV6_CGA == SHA1(X509Cert{PK} | NetworkPrefix). 7.1 Opportunistic Transport Mode Validation of the IKE_SA_AUTH only requires CGA-PK binding verification. Because the IKE peers that just prove CGA ownership will also be the endpoints of any subsequently created transport mode CHILD_SA, validation of future CREATE_CHILD_SA requests will obviously not require additional verification since the endpoints CGA's are already verified. 7.2 Opportunistic Tunnel Mode Tunnel Mode requires that an OSGW verify the PK-CBID binding of its correspondent OSGW (instead of PK-CGA), and the PK-CGA binding of the source and destination CGA's of the data packet that initially triggered this exchange. Those CGA's are embedded within the TS_i and TS_r payloads. Then the two OSGW's mutually prove themselves that they add been authorized to act as OSGW's for the traffic implied by TS_i and TS_r. o The responder verifies that it has an SPKI authorization certificate issued by the destination CGA embedded in the TS_r payload, and vice versa for the initiator. o The responder verify that it received a CERT payload containing a valid SPKI authorization certificate issued by the CGA embedded within the TS_i payload, and vice versa for the initiator. Laganier & Montenegro Expires December 29, 2003 [Page 13] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 8. Conclusion This note presents an overview of how IKE and CGA can be combined to achieve Opportunistic IPsec. The CGA technique is sufficiently well understood and can use widely deployed and implemented mechanisms. This proposal works in the absence of any previously established direct or indirect (via a broker, AAA roaming operator or trusted third party) security relationship. Because of this, these methods are a very practical and deployable means of using IPsec between previously unknown peers. Laganier & Montenegro Expires December 29, 2003 [Page 14] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 9. Security Considerations This document discusses possible use of IKE as a means to prove CGA ownership and exchange keys to bootstrap IPsec SA's. Because IKE has already been specified and this technique only slightly modifies it, we believe that this should not raise other security concerns that those incurred by CGA proof-of-ownership. Though the cryptographic algorithm used are the same, CGA proof-of-ownership is very different in nature to authentication. One must be especially careful when establishing the security policy, as this technique allows nodes that use their own IPv6 CGA to be successfully authenticated as their "owner". This is similar in essence to IKE used with self-signed certificates, with the additional consideration that CGA binds the address to the public key. A CGA may be considered as a verifiable self-generated address. The Opportunistic IPsec application of this scheme might be subject to Denial of Service (DoS) attacks. There is two types of such attacks: fake/malicious initiator and fake/malicious destination. A rogue opportunistic security gateway may attack from 'outside', trying to exhaust the gateway's resources by attempting to establish as many opportunistic IPsec tunnels as it can towards machine of the protected network prefix. This is done by initiating many IKE exchanges. The fake initiator typically sends a lot of spoofed packets with random source addresses. This does not cause much harm as the IKE exchange will not progress any further. On the other hand, the malicious initiator sends regular packets to progress into the IKE exchange. Fortunately, as the gateway will refuse an exchange that is not about protecting a node for which it had a SPKI delegation certificate, the attacker need to know which protected node to attacks to succeed in its attack. Solutions are either to perform a brute-force 'search' on a possible destination CGA while negotiating the CHILD-SA, but then the attacker is committed to complete an IKE exchange per attacked address. This might eventually lead to a detection of the attack. Laganier & Montenegro Expires December 29, 2003 [Page 15] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 10. Open Issues This document introduce a new ID payload type, ID_IPV6_CGADDR. However, it is not yet clear what is the most appropriate means of requiring peers to verify the PK-CGA binding. Other means are possible. In particular, the revised identity proposal [7] seems to fulfill the requirements for CGA's and CBID's proof-of-ownership. Laganier & Montenegro Expires December 29, 2003 [Page 16] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 11. Intellectual Property Rights Considerations The IETF takes no position regarding the validity or scope of intellectual property or other rights that might be claimed 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 implementors 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Laganier & Montenegro Expires December 29, 2003 [Page 17] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 Normative References [1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [2] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [3] Maughan, D., Schneider, M., Schertler, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. Laganier & Montenegro Expires December 29, 2003 [Page 18] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 Informative References [4] Richardson, M. and H. Redelmeier, "Opportunistic Encryption using The Internet Key Exchange (IKE)", draft-richardson-ipsec- opportunistic-11.txt (work in progress), January 2003. [5] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002. [6] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", draft-roe- mobileip-updateauth-02 (work in progress), February 2002. [7] Hoffman, P., Aura, T., O'Shea, G. and J. Arkko, "Revised Use of Identity in Successors to IKE", draft-ietf-ipsec-revised- identity-00 (work in progress), April 2002. [8] Aura, T., "Cryptographically Generated Addresses (CGA)", draft- aura-cga-00 (work in progress), February 2003. [9] Castelluccia, C. and G. Montenegro, "IPv6 Opportunistic Encryption", INRIA Research Report RR-4568, October 2002. [10] Kaufmann, C., "Internet Key Exchange version 2", draft-ietf- ipsec-ikev2 (work in progress), 2003. [11] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", IEEE ISCC 2003, July 2003. Authors' Addresses Julien Laganier ENS Lyon / Sun Microsystems, Inc. 180, avenue de l'Europe 38334 Saint Ismier CEDEX France EMail: julien.laganier@sun.com Laganier & Montenegro Expires December 29, 2003 [Page 19] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 Gabriel Montenegro Sun Microsystems, Inc. 180, avenue de l'Europe 38334 Saint Ismier CEDEX France EMail: gab@sun.com Laganier & Montenegro Expires December 29, 2003 [Page 20] Internet-Draft Using IKE with IPv6 Cryptographically Generated Address June 2003 Full Copyright Statement 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Laganier & Montenegro Expires December 29, 2003 [Page 21]