Network Working Group S. Krishnan Internet-Draft Ericsson Intended status: Standards Track November 02, 2007 Expires: May 5, 2008 Proxying Secure Neighbor Discovery Messages draft-krishnan-cgaext-proxy-send-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 May 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Krishnan Expires May 5, 2008 [Page 1] Internet-Draft Proxy SEND November 2007 Abstract Neighbor discovery(ND) proxies provide a method for bridging multiple links into a single subnet. They do this by modifying the neighbor discovery signaling passing through them. SEND provides a way of securing neighbor discovery signaling so that receiving nodes can detect if the neighbor discovery packets have been tampered with. This leads to SEND and ND proxies being unable to coexist with each other. This document proposes a method for these to co-exist. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Changes to SEND concepts . . . . . . . . . . . . . . . . . . . 5 4. Proposed method . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Pre-requisites . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Operation of a SEND proxy . . . . . . . . . . . . . . . . 6 5. Proxy Signature Option(PSO) . . . . . . . . . . . . . . . . . 7 6. Original Link Layer Address Options . . . . . . . . . . . . . 9 7. Fallback procedure . . . . . . . . . . . . . . . . . . . . . . 10 8. Backward Compatibility with legacy SEND nodes . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Krishnan Expires May 5, 2008 [Page 2] Internet-Draft Proxy SEND November 2007 1. Requirements notation 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 [RFC2119]. Krishnan Expires May 5, 2008 [Page 3] Internet-Draft Proxy SEND November 2007 2. Introduction Neighbor discovery proxies [RFC4389] describes a method by which multiple link layer segments are bridged into a single segment. SEND [RFC3971] specifies a method for securing neighbor discovery signaling [RFC4861] against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy Neighbour Discovery signaling initiated by ND proxies cannot be secured using SEND as they do not possess knowledge of the address owner's private key. Krishnan Expires May 5, 2008 [Page 4] Internet-Draft Proxy SEND November 2007 3. Changes to SEND concepts The original SEND specification [RFC3971] has implicitly assumed that the owner of the address was the one who was advertising the prefix. This assumption does not allow proxying of a CGA based address as the receiver requires that the advertiser possesses the public and private keys related to the address. So this document recommends that the roles of ownership and advertiser be explictly separated. The certificates used by SEND do not specify the purpose for which the certificate was granted. A companion document [SENDEKU] describes the extensions required to SEND certificates in order to explicitly specify the purpose of the certificate. Krishnan Expires May 5, 2008 [Page 5] Internet-Draft Proxy SEND November 2007 4. Proposed method 4.1. Pre-requisites In the proposed method the proxy becomes part of the trusted infrastructure just like a SEND router. The proxy is granted a certificate that specifies the range of addresses that it is allowed to proxy. Hosts can use the same process to discover the certification path between a proxy and one of the host's trust anchors as the one defined for routers in Section 6 of [RFC3971]. 4.2. Operation of a SEND proxy The SEND proxy performs all the operations that a standard ND proxy defined in [RFC4389] performs. It performs a few additional steps in order to ensure that the receiving node can differentiate between an authorized proxy modifying a neighbor discovery message and a malicious node doing the same. This is accomplished by signing the modified message with the authorized proxy's key. An authorized proxy will also include in the signed message, the original contents of the neighbor discovery options it replaced. This can be used by the receiving node for further verification if needed as specified in Section 7. The signature of the neighbor discovery proxy is included in a new option called the proxy signature option. The signature is performed over all the NDP options present in the message including the RSA signature option from the original message. The PSO is appended as the last option in the message. Krishnan Expires May 5, 2008 [Page 6] Internet-Draft Proxy SEND November 2007 5. Proxy Signature Option(PSO) The Proxy Signature option allows public key-based signatures to be attached to NDP messages. The format of the Proxy Signature option is described in the following diagram: 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Key Hash | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Digital Signature . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA1 Length The length of the option (including the Type, Length, Reserved, Key Hash, Digital Signature, and Padding fields) in units of 8 octets. Reserved A 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Key Hash A 128-bit field containing the most significant (leftmost) 128 Krishnan Expires May 5, 2008 [Page 7] Internet-Draft Proxy SEND November 2007 bits of a SHA-1 [14] hash of the public key used for constructing the signature. The SHA-1 hash is taken over the presentation used in the Public Key field of the CGA Parameters data structure carried in the CGA option. Its purpose is to associate the signature to a particular key known by the receiver. Such a key can either be stored in the certificate cache of the receiver or be received in the CGA option in the same message. Digital Signature A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets: 1. The 128-bit CGA Message Type tag [11] value for SEND, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been generated randomly by the editor of this specification.). 2. The 128-bit Source Address field from the IP header. 3. The 128-bit Destination Address field from the IP header. 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header. 5. The NDP message header, starting from the octet after the ICMP Checksum field and continuing up to but not including NDP options. 6. All NDP options preceding the Proxy Signature option. The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash, as defined in [13]. This field starts after the Key Hash field. The length of the Digital Signature field is determined by the length of the RSA Signature option minus the length of the other fields (including the variable length Pad field). Padding This variable-length field contains padding, as many bytes long as remain after the end of the signature. Figure 1: PSO layout Krishnan Expires May 5, 2008 [Page 8] Internet-Draft Proxy SEND November 2007 6. Original Link Layer Address Options These options contain the contents of the TLLAO and/or SLLAO options in the original unmodified packet before the proxy modified the packet to replace them with its own addresses. 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 | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA2 for Source Link-layer Address TBA3 for Target Link-layer Address Length The length of the option (including the type and length fields) in units of 8 octets. For example, the length for IEEE 802 addresses is 1 [IPv6-ETHER]. Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER]. The contents of this field are to be interpreted as described for the SLLAO and the TLLAO options described in RFC4861. Figure 2: OLLAO layout Krishnan Expires May 5, 2008 [Page 9] Internet-Draft Proxy SEND November 2007 7. Fallback procedure If a receiving node does not trust a proxy it may elect to use the original contents of the received neighbor discovery message instead of the received contents. The original message can be derived as follows o Replace the contents of the TLLA option, if any, with the contents of the OTLLA option while retaining the type field of the option o Replace the contents of the SLLA option, if any, with the contents of the OSLLA option while retaining the type field of the option o Reset the value of the P bit if the received message is a Router Advertisement o Remove any proxy signature, OTLLA, and OSLLA options present in the message After obtaining the contents of the original message the receiving node can perform SEND verification as described in [RFC3971] Krishnan Expires May 5, 2008 [Page 10] Internet-Draft Proxy SEND November 2007 8. Backward Compatibility with legacy SEND nodes The options added by a SEND proxy, such as the PSO, will not be used by nodes implementing the original SEND specification and hence will not cause any interoperability problems. These legacy SEND nodes will check the RSA signature option and will consider it invalid. Based on the configuration of the host, the message MAY either be treated as insecure or be dropped. Krishnan Expires May 5, 2008 [Page 11] Internet-Draft Proxy SEND November 2007 9. Security Considerations The mechanism described in this document provides a method by which a neighbor discovery proxy can replace the link layer address in any neighbor discovery message with its own. The nodes receiving such modified advertisements need to verify whether the proxy has been authorized to perform the changes. For this the nodes depend on a certificate issued to proxies, to authorize such changes. Krishnan Expires May 5, 2008 [Page 12] Internet-Draft Proxy SEND November 2007 10. IANA Considerations This document uses three new neighbor discovery options and requests the allocation of three different IPv6 Neighbor Discovery Option types for each of these options. The values to be allocated are denoted in the document as TBA1, TBA2 and TBA3. The values need to be allocated from the namespace specified in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at http://www.iana.org/assignments/icmpv6-parameters. Krishnan Expires May 5, 2008 [Page 13] Internet-Draft Proxy SEND November 2007 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [SENDEKU] Krishnan, S., "Authorization Certificates for Routers and Proxies", Internet-Draft draft-krishnan-cgaext-send-cert-eku-00, October 2007. Krishnan Expires May 5, 2008 [Page 14] Internet-Draft Proxy SEND November 2007 Author's Address Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 Email: suresh.krishnan@ericsson.com Krishnan Expires May 5, 2008 [Page 15] Internet-Draft Proxy SEND November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Krishnan Expires May 5, 2008 [Page 16]