CGA and SeND Maintenance (CSI) W. Haddad Internet-Draft M. Naslund Intended status: Standards Track Ericsson Research Expires: July 9, 2008 January 6, 2008 On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship draft-haddad-cgaext-symbiotic-sendproxy-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 July 9, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Haddad & Naslund Expires July 9, 2008 [Page 1]
Internet-Draft Proxy SeND January 2008 Abstract This document introduces a simple mechanism which enables a host using IPv6 cryptographically generated address to delegate the task of secure neighbor discovery proxying to another node by means of establishing a "symbiotic" relationship with that node. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. What is a 'Symbiotic' Relationship? . . . . . . . . . . . . . 6 5. Applying SR in a SeND environment . . . . . . . . . . . . . . 8 5.1. Using SR for SeND Proxying . . . . . . . . . . . . . . . . 9 6. New Option . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Haddad & Naslund Expires July 9, 2008 [Page 2]
Internet-Draft Proxy SeND January 2008 1. Introduction Secure neighbor discovery protocol [SeND] enables establishing a trust relationship between hosts attached to the same link and/or between host and its access routers (ARs). SeND achieves its goal by using IPv6 cryptographically generated address ([CGA]) on the host side and deploying a local public key infrastructure in the access network. When SeND protocol is applied, all router adverstisement (RtAdv) messages as well as any neighbor discovery protocol (described in [NDP]) message sent by an AR are signed. In addition, any host can configure a CGA-based IPv6 address and use its properties to provide a "proof of ownership" when exchanging NDP messages with other hosts located on the same link. This document introduces a simple mechanism which enables a host using CGA IPv6 address to delegate the task of SeND proxying to its AR by means of establishing a new and unique form of distant relationship that we refer to in the rest of this document as "symbiotic". Haddad & Naslund Expires July 9, 2008 [Page 3]
Internet-Draft Proxy SeND January 2008 2. 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 [TERM]. Haddad & Naslund Expires July 9, 2008 [Page 4]
Internet-Draft Proxy SeND January 2008 3. Motivation Our motivation behind this work is three-fold: o provide secure assistance for mobile node (MN) while being active but away from their home link, e.g., case of mobile IPv6 protocol (more below). o enable a weak (still to be improved) form of anonymity on the link by enabling a particular host to avoid disclosing its CGA public key especially when switching between different links. o extend SeND proxying assistance in some particular scenarios, to static/mobile host which is not CGA enabled. Haddad & Naslund Expires July 9, 2008 [Page 5]
Internet-Draft Proxy SeND January 2008 4. What is a 'Symbiotic' Relationship? A symbiotic relationship (SR) is a unidirectional association between two nodes A and B. This means that when node A establishes an SR with node B, then node B is assumed to be the only node which is able to advertise such relationship to a third party and to provide a "proof of relationship (PoR)" (i.e., similar to providing a CGA proof of ownership) with node A. Consequently, establishing an SR with a node B can empower it to act on behalf of node A, i.e., if/when needed and regardless of the node A's current location. It follows that establishing a bidirectional SR between nodes A and B enables any of them to act on behalf of the other and also to provide each a different PoR to a third party. Furthermore, a node is also able to establish different SRs with a group of nodes in a single operation. Once established, each node from the group has to extract the specific SR which shows its own involvment, i.e., by re-arranging the parameters, in order to prove it to a third party. A key element in the CGA mechanism is to generate a 128-bit random RAN(128) parameter which must be sent (among others) to the receiver in order to enable it to re-compute the CGA IPv6 address before verifying the signature. When establishing an SR from node A to node B, the only required modification occurs around the RAN(128) generated by A when configuring a CGA address. The suggested modification consists on replacing the RAN(128) with another new random 128-bit (we call it SR_RAN(128)) which in turn, is generated from the RAN(128) and B's public key (Kp). The new RAN(128), i.e., SR_RAN(128), is obtained from concatenating the previous RAN(128) with B's Kp then hashing the concatenation. After that, A takes the first 128 bits of the resulting hash and uses it as the SR_RAN(128) which will replace the previous RAN(128) when computing the 64-bit interface identifier (IID) for its CGA IPv6 address. In summary the previous RAN(128) used to generate the IID without SR is in fact dissolved in the new one, i.e., SR_RAN(128) which is now used for generating A's IID. The rule for computing an SR_RAN(128) when establishing an SR with a node using Kp as public key is is as follows: SR_RAN(128) = First[128, Hash(Kp | RAN(128)] Where: - First(size, input) indicates a truncation of the "input" data so that only the first "size" bits remain to be used. - RAN(128) is the 'previous' 128-bit random parameter which was supposed to be used for configuring a CGA address without an SR. Haddad & Naslund Expires July 9, 2008 [Page 6]
Internet-Draft Proxy SeND January 2008 - "|" denotes a concatenation - The recommended hash function is SHA256 Haddad & Naslund Expires July 9, 2008 [Page 7]
Internet-Draft Proxy SeND January 2008 5. Applying SR in a SeND environment We assume in the following that a CGA-enabled host (H) is attaching to a link where SeND protocol is deployed and used by the AR to sign its router advertisement (RtAdv) messages. This means first, that (H) can securely get a copy of AR's certificate and trust its content. As previously shown, establishing an SR between a host and an AR is a simple procedure which does not introduce any change in the mechanism designed for configuring a CGA IPv6 address per se. fact, the introduced modification occurs in the "background" of the CGA mechanism. This means that if a host (H) decides to not disclose immediately the SR, i.e., how the SR_RAN(128) has been computed from the AR's Kp, then it can keep using CGA as it has been defined by simply using SR_RAN(128) as a normal RAN(128) parameter. After computing the new SR_RAN(128) parameter, (H) proceeds to generate its IPv6 address as defined in the CGA mechanism. When (H) needs to disclose the SR to its AR, e.g., to request proxying services, then it has to insert the RAN(128) used to generate the SR_RAN(128) in a new option (called SRO) to be carried, for example, in the router solicitation (RtSol) message sent to the AR or in an NDP message. In addition, (H) SHOULD encrypt SRO using the AR's Kp. Upon receiving a RtSol message carrying an SRO, the AR should first check the SR validity. This is achieved by decrypting the SRO then checking if the IPv6 address is generated from using its own Kp. If the check is valid, then the AR should proceed to check the address ownership and verify the signature. After that, the AR SHOULD store the host's RAN(128) together with its IP address, public key and all associated CGA parameters. It follows that if (H) decides not to reveal its SR to its AR, then it can continue using SeND protocol by disclosing only its new SR_RAN(128) parameter. It should be noted also that an AR MUST NOT accept an SR sent by a node which has configured a CGA IPv6 address unless the message carrying the SR is signed by the node's CGA private key. When establishing different SRs with a group of nodes having each a public key, the host needs to concatenate all group nodes public keys with the RAN(128) before hashing the concatenation and taking the first 128 bits resulting from the hash as its SR_RAN(128). As mentioned earlier, each node from the group should be able to extract the specific SR which involves its public key and uses other group nodes public keys together with the RAN(128) as parameters to be sent to a third party when disclosing the specific SR. As mentioned earlier, a key feature of SR is that it restricts the Haddad & Naslund Expires July 9, 2008 [Page 8]
Internet-Draft Proxy SeND January 2008 ability to prove its existence to a third party to the owner of the public key which is hashed with the RAN(128). When such situation arises, e.g., AR needs to act on behalf of (H), then it may have to show such privilege by disclosing the SR to the third party and providing a "proof of relationship". This is done by adding (H)'s IPv6 address and all CGA components that (H) has used to generate it. These components MUST include RAN(128) and the AR's public key instead of the SR_RAN(128) parameter. In addition, the AR MUST sign the message. It follows that no other node can claim the same privilege of acting on behalf of (H) unless it can discover AR's private key in order to correctly sign the message. We assume such scenario to be highly unlikely. The other alternative for a malicious node to claim the same SR with (H) is to generate another key pair then try to re-build the whole chain of parameters which leads to the same IPv6 address used by (H). Another possibility to explore is to use SR by a non-CGA host in a SeND environment. For this purpose, (H) has to derive its IPv6 address by applying the same rule mentioned earlier with the difference that it has to take the first 64-bit and use them as interface identifier for configuring the IPv6 address. In such scenario, the host has to send a RtSol message to the AR in which, it has to include the SRO and encrypts it with AR's Kp. Note however, that the RtSol message in this case won't be signed. Such feature may prove very useful for low processing power device as it allows it to delegate neighbor discovery proxying task to its AR in order to be done securely. However, it should be manipulated with great care and requires more investigation. Another path which requires more investigation is related to manipulating SR in stateful address configuration and always in a SeND environment. In fact, it may be possible to have an SR automatically established between a host and its AR when stateful address configuration is in place. This can be done by enabling the DHCP to generate IPv6 addresses to be allocated to hosts, in the same way as described for non-CGA host. The CGA MUST then share the RAN(128) with the AR without the host knowledge nor involvement. In such scenario, the AR may signal to the host its ability to act on its behalf by setting a bit in the RtAdv message. 5.1. Using SR for SeND Proxying It follows from the above that SR simplicity and efficiency makes it a suitable candidate for enabling SeND proxying to mobile/static hosts. In order to do so, each host has to establish an SR with the secure NDP proxying node (which may be the AR itself). In case, the AR is not empowered to offer NDP proxying services, then it SHOULD advertise -at least- the public key(s) of the node(s) which is Haddad & Naslund Expires July 9, 2008 [Page 9]
Internet-Draft Proxy SeND January 2008 playing this role. Upon receiving an additional public key(s) in the RtAdv message sent by AR, (H) may decide to use it to establish an SR with its holder either directly or via the AR. As we're assuming that SeND protocol is deployed, which means first and foremost that (H) can trust the access infrastructure and the information that it is sending (and also validate it), then we can also assume with the same level of trust that the additional public key(s) advertised by the AR is also genuine and is owned by the real node offering proxying services. Following a decision to delegate secure NDP proxying services to the owner of the public key sent in the RtAdv messages, (H) applies the rule described earlier to establish an SR with the proxying node when configuring its CGA IPv6 address. Once the CGA address uniqueness is ensured, (H) can start using as a normal CGA address as long as it does not need to request a proxying service. One way to trigger delegating SeND NDP proxying task is to disclose the SR parameter to the AR and/or the node dedicated for that task. This can be done for example by sending a RtSol message at any moment which carries the RAN(128) in an SRO. Note that (H) SHOULD encrypt the RAN(128) with the proxying node's public key. After sending such RtSol message, (H) SHOULD stop replying to any NDP querry. In other words, (H) will be able to decide when to "vanish" from the link whenever it sees it appropriate. Furthermore, and for privacy purposes, the MN may decide to delegate the proxying task even while being physically attached to the link, in order to avoid disclosing its own CGA public key when signing NDP messages. In fact, disclosing the public key can severely harm the unlinkability aspect especially when the MN is using pseudo-IPv6 address(es) when switching between different links. This may be the case for example, when performing IP handoff between different ARs while trying to keep a certain level of location privacy which should not be broken by disclosing the CGA public key. When acting as a SeND NDP proxy on behalf of (H), the dedicated node MAY include in the NDP message sent on behalf of the host all its CGA parameters as well as the RAN(128) in order to enable the querier node to derive the host's IPv6 address before checking the NDP message validity. However, as the proxying node's public key is advertised by the trusted AR, such node can simply sign the NDP message sent on behalf of (H). In order to protect against replay attacks, the querier node MUST always use a nonce in each query sent to the proxying node. The nonce MUST be returned in the response sent by the proxying node, in order to put an implicit lifetime, i.e., by associating the response to the query which triggered it. Note that, in case the queried IPv6 address cannot be computed from Haddad & Naslund Expires July 9, 2008 [Page 10]
Internet-Draft Proxy SeND January 2008 parameters sent by the AR, the querier node MUST silently discard the message. Mobile IPv6 protocol (described in [MIPv6]) is a typical scenario where a mobile node (MN) needs to stay attached to its home link, i.e., via its home agent (HA), even when being physically attached to a foreign one. In this case, the HA is supposed to act on behalf of the MN and respond to any NDP querry sent on the home link. Based on the above, all what the MN needs to do is to establish and activate an SR with its HA, regardless of its topological location (i.e., the MN may boostrap while being attached to a foreign link). Haddad & Naslund Expires July 9, 2008 [Page 11]
Internet-Draft Proxy SeND January 2008 6. New Option TBD Haddad & Naslund Expires July 9, 2008 [Page 12]
Internet-Draft Proxy SeND January 2008 7. Security Considerations This memo describes a mechanism which enables a host to delegate the task of performing SeND NDP proxying to another node by means of establishing a new type of relationship with that node. In its current form, the new mechanism is built on top of CGA technology. The security of such delegation is inherited from the existence of a SeND environment which enables a host to establish a form of trust with the access router(s). In our proposal, we assume that such trust will be expanded to the relation between the host and the proxying node(s), i.e., in case such node is not the AR itself. This means first and foremost, that the access router is advertising the right public key(s) owned by the real proxy node(s). It also means that the same kind of trust can be assumed to reign between any host located on the same link than the 'proxied' host and the proxy node. Under such assumption, whenever the proxy node needs to disclose the SR relationship to a third party, e.g., querier node, it can only show the SR components in a message that must be signed with the proxy node's private key. However, in the absence of the assumed trust between the querrying node(s) and the proxy node(s), then the latter must include the proxied node signature in the proof of relationship that it may need to disclose. Furthermore, in such environment, the proxied's node signature cannot have an unlimited lifetime. Consequently, the proxied node has to bind its signature to a fixed lifetime after which, it becomes obsolete unless it is refreshed by the proxied node. An alternative may be to announce a pre-defined lifetime for any proxying request. It follows that in such scenario, the proxied node's public key has to be disclosed to the queried node, which in turn may preserve the queried node's location privacy but certainly hurt any anonymity and unlinkability goals. Note that a direct consequence of a binding between signature and lifetime is a requirement for synchronization between the proxying node and the querying one(s). As the proposal offers some first hints and suggestions on how to extend the 'symbiotic' relationship concept to non-CGA node and stateful address configuration, it certainly raises new security concerns mainly related to how the SR can be sent to the right node in such environment. These security concerns won't be detailed in this version as the concept is still in an early stage. Haddad & Naslund Expires July 9, 2008 [Page 13]
Internet-Draft Proxy SeND January 2008 8. Normative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3792, March 2005. [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support for IPv6", RFC 3775, June 2004. [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. Nikander, "Secure Neighbor Discovery (SeND)", RFC 3971, March 2005. [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, BCP , March 1997. Haddad & Naslund Expires July 9, 2008 [Page 14]
Internet-Draft Proxy SeND January 2008 Authors' Addresses Wassim Haddad Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden Phone: +46 8 4044079 Email: Wassim.Haddad@ericsson.com Mats Naslund Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden Phone: +46 8 58533739 Email: Mats.Naslund@ericsson.com Haddad & Naslund Expires July 9, 2008 [Page 15]
Internet-Draft Proxy SeND January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Haddad & Naslund Expires July 9, 2008 [Page 16]