Network Working Group P. Nikander Internet-Draft Ericsson Research Nomadiclab Expires: December 18, 2003 June 19, 2003 Secure Neighbor Discovery using separate CGA extension header draft-nikander-send-ipsec-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 18, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The Secure Neighbor Discovery (SEND) Working Group has produced an Internet Draft that proposes to use an IPsec AH header that carries both a public key and a signature. However, based on the recent discussion at the mailing lists it seems that such a usage of AH is considered inappropriate at least by some members of the IPSEC WG. In this draft we introduce an alternative method, where a separate extension header is used to carry the public key, and the AH header only contains a signature. Nikander Expires December 18, 2003 [Page 1] Internet-Draft SEND with CGA ext June 2003 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Modifications to Neighbor Discovery . . . . . . . . . . . . 4 3. CGA based Inline Key Management Protocol (IKMP) . . . . . . 5 3.1 Processing rules for outgoing packets . . . . . . . . . . . 6 3.2 Processing rules for incoming packets . . . . . . . . . . . 6 4. Certificate based Key Management Protocol (KMP) . . . . . . 8 5. IPsec Extensions . . . . . . . . . . . . . . . . . . . . . . 9 5.1 The AH_RSA Algorithm . . . . . . . . . . . . . . . . . . . . 9 5.1.1 Reserved SPI Number . . . . . . . . . . . . . . . . . . . . 9 5.2 AH_RSA Security Associations . . . . . . . . . . . . . . . . 9 5.3 Processing Rules for Senders . . . . . . . . . . . . . . . . 9 5.4 Processing Rules for Receivers . . . . . . . . . . . . . . . 9 6. Other IPsec Extensions . . . . . . . . . . . . . . . . . . . 11 6.1 Destination Agnostic Security Associations . . . . . . . . . 11 6.2 ICMP Type Specific Selectors . . . . . . . . . . . . . . . . 11 7. Other functionality . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 A. IPR Considerations . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . 15 Nikander Expires December 18, 2003 [Page 2] Internet-Draft SEND with CGA ext June 2003 1. Overview IPsec AH is used in to protect Neighbor and Router Discovery messages. This specification introduces a new extension header, which creates a new Inline Key Management Protocol (IKMP), a new public key algorithm for IPsec AH, a couple of small modifications to the proposed IPsec selectors in AHbis [4], and an address ownership proof mechanism. This document does not propose any changes to the authorization delegation discovery process presented in the official working group draft. [5] The components of the solution specified in this document are as follows: o IPsec AH is used to protect all messages relating to Neighbor and Router discovery. o Cryptographically Generated Addresses are used to assure that the sender of a Neighbor or Router Advertisement is the owner of an the claimed address. Alternatively, certificates could be used for this, using a certificate based KMP, but such protocol is not specified in this document. A public-private key pair needs to be generated by all nodes before they can claim an address. o IPsec security policy database is configured to provide the protection. Note that such configuration may take place manually or the operating system may perform it automatically upon enabling Secure Neighbor Discovery. Security Associations are created on the fly, using the IKMP. This specification introduces extensions to the required selectors used in security policy database entries. This is necessary in order to enable the protection of specific ICMP message types, while leaving other messages unprotected. Additionally, it must be possible to select the correct Security Association (SA) based on the source address in an incoming packet. o A new IPv6 extension header is used to generate public key based security associations on the fly. The trust to the public key is established either with an authorization delegation process (which is unspecified in this document) or the presented address ownership proof mechanism, depending on configuration and the type of the message protected. o A new algorithm for IPsec AH allows public keys to be used on a security association. Symmetric session keys are not used, public key signatures are used instead. Nikander Expires December 18, 2003 [Page 3] Internet-Draft SEND with CGA ext June 2003 2. Modifications to Neighbor Discovery This document proposes the same modifications to the IPv6 ND protocol than the official working group draft [5] does, namely the following: o The use of the unspecified address as a source address is discouraged. o The solicited-node multicast address is replaced with the securely-solicited-node multicast address. o The Nonce option is required in all Neighbor Discovery solicitations, and for all solicited advertisements. o Proxy Neighbor Discovery is not supported in this specification (it will be specified in a future document). See the working group draft [5] for a full explanation of these changes. Nikander Expires December 18, 2003 [Page 4] Internet-Draft SEND with CGA ext June 2003 3. CGA based Inline Key Management Protocol (IKMP) A new IPv6 extension header is used to define an Inline Key Management Protocol (IKMP), used to create IPsec AH Security Associations. The lifetime of such a SAs is limited to the handling of the particular packet. That is, once the packet has been processed, the SA is discared. The new extension header MUST be placed before the AH header. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | RES | PAD |CC | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Modifier | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Public key . . (variable length, with padding at the end) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields have the following definitions: Next Header The following IP extension header, typically AH. Hdr Ext Len Length of the extension header, as defined in RFC2461 [1]. RES Reserved. Zero when sent and ignored when received. PAD Number (0-7) of padding octets following the public key. CC CGA Collision Count, as defined in [6]. Algorithm Public key algorithm used, as defined in RFC2535 [2]. Nikander Expires December 18, 2003 [Page 5] Internet-Draft SEND with CGA ext June 2003 RESERVED Placeholder for a potential extension that would allow the SA to be used for longer than just processing the one packet. Timestamp Timestamp, in millisecond granularity. See the discussion in the working group draft [5]. Modifier CGA Modifier, as defined in [6]. Public key CGA Public key, in RFC2535 [2] format. For RSA, RFC3110 [3] is used. 3.1 Processing rules for outgoing packets In a conforming host, there can be both CGA and non-CGA addresses in parallel. A CGA address in an address that has been generated according to the CGA method, and is associated with a Collision Count, Modifier, and Public key. The rules of this section apply only when using a CGA source address. When sending a packet using a CGA address as a source address, the host SHOULD add the CGA extension header to the outgoing packet. If the packet is IPsec protected, the header MUST be added in prior to IPsec processing, so that the possible AH signature covers the header. The header MUST be placed between the IP header and the AH header, so that it is processed before the AH header at the receiving end. The PAD, CC, Algorithm, Modifier and Public Key fields must be filled according to the CGA specification and the associated address generation. The details are left for future work, but follow the ideas from the CGA specification [6]. 3.2 Processing rules for incoming packets Upon encountering an CGA extension in an incoming packet, the following processing rules apply. The receiver forms CGA parameters from the routing prefix in the IPv6 source address in the IP header, the CC, Algorithm, Modifier and Public Key fields in the CGA extension header, and performs the CGA verification on the resulting CGA parameters structure. The details are left for future work, but follow the ideas from the CGA specification [6]. If the CGA verification fails, the packet MUST be silently dropped. If the CGA verification succeeds, the host creates a new IPsec AH Nikander Expires December 18, 2003 [Page 6] Internet-Draft SEND with CGA ext June 2003 security association. The new assocation has a fixed, pre-configured SPI, and is selected based on the SPI and the source address. Alternatively, the CGA header could itself carry the SPI, but the security implications of that has not been analyzed sufficiently much. The resulting SA is defined as follows. +------------------------------------------------------+ | Name | Direction | SPI | Proto | Dst | Source | +------------------------------------------------------+ | CGA_In | Inbound | To be | AH | Any | From | | | | assigned | | | the | | | | by IANA | | | IP hdr | +------------------------------------------------------+ The lifetime of the SA is one packet. (Implementation note: Possibly the easiest way of implementing the SA is to attach it as meta-data to the packet being processed.) Nikander Expires December 18, 2003 [Page 7] Internet-Draft SEND with CGA ext June 2003 4. Certificate based Key Management Protocol (KMP) Using the multicast based certificate discovery mechanism specified in the working group draft [5], it is possible to define a Key Management Protocol that creates public key based security associations. Such SAs could be used in the place of a CGA based SAs. However, the details of that are left for future work. Nikander Expires December 18, 2003 [Page 8] Internet-Draft SEND with CGA ext June 2003 5. IPsec Extensions 5.1 The AH_RSA Algorithm The AH_RSA algorithm specifies how AH can be used with a public key, bound to the sender IP address. This transform introduces the use of a new reserved SPI number and a new format for the Integrity Check Value (ICV) field in AH. 5.1.1 Reserved SPI Number The AH_RSA MUST be only be used with the reserved SPI number TBD . 5.2 AH_RSA Security Associations Incoming security associations that specify the use of AH_RSA transform MUST record the following additional configuration information: publickey Public key to verify the signature. Outgoing security associations MUST record the following additional information: keypair A public-private key pair. 5.3 Processing Rules for Senders A node sending a packet using the AH_RSA algorithm MUST construct the packet as follows: o The Next Header, Payload Len, and Reserved fields are set as described in RFC 2402. o The Security Parameters Index is set to the value specified in Section 5.1.1. o The packet, in the form defined for AH's coverage, is signed using the private key in the security association, and the resulting PCKS #1 signature is put to the Integrity Check Value field. 5.4 Processing Rules for Receivers A packet received on a security association employing AH_RSA transform MUST be checked as follows: Nikander Expires December 18, 2003 [Page 9] Internet-Draft SEND with CGA ext June 2003 o Next Header and Payload Len fields are valid as specified in RFC 2402. o The SPI field is equal to the value defined in Section 5.1.1. o The Digital Signature in the Integrity Check Value is verified using the public key from the Security Association. Packets that do not pass all the above tests MUST be silently discarded. Nikander Expires December 18, 2003 [Page 10] Internet-Draft SEND with CGA ext June 2003 6. Other IPsec Extensions 6.1 Destination Agnostic Security Associations In order to allow the same security association to be used when the the node sends packets to different peers using the same addresses, an extension must be provided to the RFC 2401 rules on how security associations are identified. This change is particularly important, for instance, when routers use the same keys and security association to send Router Advertisements for up to number of prefixes x 2^64 hosts on an interface. This extension is mandatory for all nodes that support the AH_RSA algorithm. Security associations that use the SPI value specified in Section 5.1.1 MUST be identified based on the SPI, the protocol numbers, and the source address, but not by the destination IP address. Note that this extension can be supported with a very small implementation modification if the proposed revisions of the IPsec standards are in use [4]. More specifically, the only required modification is to allow incoming SA selection to be based on source address while ignoring the destination address. Currently such usage is not defined. 6.2 ICMP Type Specific Selectors In order to allow finer granularity of protection for various ICMPv6 messages, it is necessary to extend the security policy database and security association selectors with the capability to distinguish between different messages. All nodes that support Secure Neighbor Discovery MUST be capable of using ICMP and ICMPv6 Type field as a selector. Note that this can be achieved in an implementation by using the port number field to contain the ICMP type if the protocol field is ICMP. Nikander Expires December 18, 2003 [Page 11] Internet-Draft SEND with CGA ext June 2003 7. Other functionality In most other respects, this proposal follows the official working group document. No other changes are currently proposed, but they are likely to emerge as this proposal matures. Nikander Expires December 18, 2003 [Page 12] Internet-Draft SEND with CGA ext June 2003 Normative References [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [3] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. [4] Kent, S., "IP Authentication Header", draft-ietf-ipsec-rfc2402bis-03 (work in progress), April 2003. [5] Arkko, J., "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-01 (work in progress), June 2003. [6] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-aura-cga-00 (work in progress), February 2003. Author's Address Pekka Nikander Ericsson Research Nomadiclab Jorvas 02420 Finland EMail: Pekka.Nikander@nomadiclab.com Nikander Expires December 18, 2003 [Page 13] Internet-Draft SEND with CGA ext June 2003 Appendix A. IPR Considerations The CGA method uses public keys and hashes to prove address ownership. Several IPR claims have been made about such methods. Nikander Expires December 18, 2003 [Page 14] Internet-Draft SEND with CGA ext June 2003 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 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. 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 assignees. 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 Nikander Expires December 18, 2003 [Page 15] Internet-Draft SEND with CGA ext June 2003 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. Nikander Expires December 18, 2003 [Page 16]