Network Working Group J. Laganier Internet-Draft ENS Lyon / Sun Microsystems, Inc. Expires: August 25, 2003 G. Montenegro Sun Microsystems, Inc. February 24, 2003 Using IKE with IPv6 Cryptographically Generated Address draft-laganier-ike-ipv6-cga-00 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 August 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes IKE peer authentication via IPv6 Cryptographically Generated Addresses. These have been proposed to solve several security issues in the absence of any trusted infrastructure. Laganier & Montenegro Expires August 25, 2003 [Page 1] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 2. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Node Configuration and Requirements . . . . . . . . . . . . . 5 4. ISAKMP Payload use . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Identification Payload . . . . . . . . . . . . . . . . . . . . 6 4.2 Certificate Payload . . . . . . . . . . . . . . . . . . . . . 6 4.3 Certificate Request Payload . . . . . . . . . . . . . . . . . 6 4.4 Authentication Payload . . . . . . . . . . . . . . . . . . . . 7 5. Authentication of the IKE Security Association . . . . . . . . 8 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Intellectual Property Rights Considerations . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Laganier & Montenegro Expires August 25, 2003 [Page 2] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 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. 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 trusted infrastructure, for example, securing Binding Updates in Mobile IPv6, securing Neighbor Discovery for IPv6, and securing Group Membership in Multicast and Anycast communications. Laganier & Montenegro Expires August 25, 2003 [Page 3] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 2. Related work The lack of a global, Internet-wide, trusted infrastructure is at the heart of these issues. This precludes 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 cryptographic techniques commonly known as CGA or SUCV. CGA usage has lacked generality as it has been applied either within specific frameworks like Mobile IP ([4], [5]) or using its own custom protocol, Statistically Unique and Cryptographically Verifiable protocol (sucvP) [4]. Lately, a proposal using Just Fast Keying (JFK) has been put forth ([6]). 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 August 25, 2003 [Page 4] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 3. Node Configuration and Requirements Each node that want to prove address ownership via CGA generates a public-private key pair, PK and SK, respectively. The nodes then use P to obtain and configure a CGA as specified in [4]: CGA = NetworkPrefix | SHA1_64 ( PK ) 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. Laganier & Montenegro Expires August 25, 2003 [Page 5] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 4. ISAKMP Payload use A peer wanting to prove CGA ownership while exchanging keys with IKE has to use ISAKMP payloads in a specific manner. Following subsections describes the requirements on those of the ISAKMP payloads that need it while doing an IKE phase 1 exchange with CGA proof-of-ownership. 4.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. 4.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. Though several types of certificates are specified in [1], we only use those that contains a public key, namely PKCS7_WRAPP_X509_CERT, PGP_CERT, DNS_SIGNED_KEY, X509_CERT_SIGNATURE and SPKI_CERT. A peer wanting to prove CGA ownership MUST use a CERT payload that contains the public key used when generating its CGA. 4.3 Certificate Request Payload The Certificate Request (CERTREQ) Payload is used by a peer to request preferred certificates to its correspondent. A preference is 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 the public key embedded in a CA-signed certificate. Laganier & Montenegro Expires August 25, 2003 [Page 6] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 4.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 have 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. A peer wanting to prove CGA ownership MUST use an AUTH payload that contains the digital signature computed using the private key associated with its CGA. Laganier & Montenegro Expires August 25, 2003 [Page 7] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 5. Authentication of the IKE Security Association [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. On nodes that want to verify address ownership, IKE implementation should be modified to handle the case of CGA verification which is very similar to already implemented self-signed certificates one. Apart from verifying the self-signed certificate, the implementation MUST verify that the public key contained in the certificate generate the address used in the identity payload as detailed above. Laganier & Montenegro Expires August 25, 2003 [Page 8] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 6. Conclusion This note presents an overview of how IKE and CGA can be combined to achieve CGA proof-of-ownership authentication. 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 August 25, 2003 [Page 9] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 7. Security Considerations This document discusses possible use of IKE as a means to prove CGA ownership and exchange keys to bootstrap IPsec SAs. Because IKE has already been specified and this technique only slightly modify it, we believe that this should not raise others 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. Laganier & Montenegro Expires August 25, 2003 [Page 10] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 8. 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. Laganier & Montenegro Expires August 25, 2003 [Page 11] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 9. 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 August 25, 2003 [Page 12] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 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 August 25, 2003 [Page 13] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 2003 Informative References [4] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002. [5] 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. [6] Castelluccia, C. and G. Montenegro, "IPv6 Opportunistic Encryption", INRIA Research Report RR-4568, October 2002. [7] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", draft- irtf-gsec-sgmv6-00 (work in progress), April 2002. Authors' Addresses Julien Laganier ENS Lyon / Sun Microsystems, Inc. 180, avenue de l'Europe 38334 Saint Ismier CEDEX France EMail: julien.laganier@sun.com Gabriel Montenegro Sun Microsystems, Inc. 180, avenue de l'Europe 38334 Saint Ismier CEDEX France EMail: gab@sun.com Laganier & Montenegro Expires August 25, 2003 [Page 14] Internet-Draft Using IKE with IPv6 Cryptographically Generated AddressFebruary 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 August 25, 2003 [Page 15]