Source Address Verification W. Haddad Architecture (SAVA) M. Naslund Internet-Draft Ericsson Research Expires: January 2, 2008 C. Vogt Ericsson Research Nomadic Lab July 1, 2007 Enabling Source Address Verification via Prefix Reachability Detection draft-haddad-sava-prefix-reachability-detection-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 January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Haddad, et al. Expires January 2, 2008 [Page 1] Internet-Draft Location Authentication July 2007 Abstract In this memo, we introduce an approach called "Prefix Reachability Detection", which aims to address certain man-in-the middle misbehavior problems and enable a location-based authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Motivation and Assumptions . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. New Options and Messages Formats . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Haddad, et al. Expires January 2, 2008 [Page 2] Internet-Draft Location Authentication July 2007 1. Introduction In this memo, we introduce an approach called "Prefix Reachability Detection (PRD)", which aims to address certain man-in-the middle (MiTM) misbehavior problems on the IP layer and enable a location- based authentication. A direct consequence of applying the PRD approach is a source address verification mechanism, which can also be used in a mobile and multihomed environment. The main components for applying the PRD protocol are a secure and trustable "prefix routing lookup" mechanism and a secure on-demand query/response between the communicating endpoints and their first hop routers. Haddad, et al. Expires January 2, 2008 [Page 3] Internet-Draft Location Authentication July 2007 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, et al. Expires January 2, 2008 [Page 4] Internet-Draft Location Authentication July 2007 3. Motivation and Assumptions The motivation behind this work stems from the need for an efficient and scalable solution to thwart MiTM misbehavior. In fact, a MiTM misbehavior can manifest itself in different aspects, which include unwanted traffic, impersonation, identity theft, denial-of service (DoS). All these aspects can target a network and/or a particular node but they share the same disruptive and destructive goals. They also have one common feature reflected by the alarming and steadily increasing frequency of their occurrence. Consequently, there is an urgent need to address this problem to avoid what could be (very) unpleasant real-world side-effects. Our goal is to provide a solution, which can protect against these different aspects by enabling a source address verification mechanism and at in parallel, offer a set of attributes which can significantly improve the security and the overall efficiency of different types of new and existing solutions. These attributes can be seen as consequences, which fall beyond addressing the SAVA problem statement described in [SAVA]. In order to achieve our goal, we make the following assumptions: - Existence of a secure and trustable mechanism, which enables at least a particular set/class of routers to fetch security credentials (i.e., using a third entity) of other routers belonging to the same set. Such mechanism can be based for example, on the ongoing work on [SIDR]. - Existence of secure and trustable links between each endpoint and the first hop router. Note that this does not really impose new requirements and has already been addressed in [SeND]. Haddad, et al. Expires January 2, 2008 [Page 5] Internet-Draft Location Authentication July 2007 4. Protocol Overview The suggested approach enables one endpoint to check the topological location of the other endpoint, which maps correctly to the prefix claimed in their IP address. Such procedure is also referred to by "location authentication". The PRD protocol is performed in parallel with running a key exchange protocol, e.g., [IKEv2] or [HIP]. In the following, we consider the classic scenario where a client (C) is establishing an IKEv2 session with a server (S) and we delegate to (S) the task of triggering the PRD protocol. In its most generic form, the PRD protocol consists on executing (in order) the following steps: 1. After completing the IKEv2 exchange, (S) requests from its first hop router (we call it AR(S)) to perform a prefix reachability detection, i.e., location authentication, on (C)'s IP address. For this purpose, (S) sends a "Prefix_Reachability_Request (PRR)" message to AR(S), which carries a secret (called Ksh) and (C)'s IP address. Ksh is derived from the hash of IKEv2 session key (Ks) and a hint (H). The PRR message MUST be signed with (C)'s CGA private key (as described in [CGA]) and the option carrying Ksh MUST be encrypted with AR(S) public key. Note that an optimized version of the SeND protocol (described in [OpSeND]) enables (S) and AR(S) to authenticate all messages exchanged between them by using a shared secret, which in turn eliminates the burden of using private/public key to sign (and encrypt) the PRR message. (C) and (S) MUST use the same method to derive Ksh. This method SHOULD be: Ksh = First[ 128, Hash[ Hash(Ks) | IID(C) | IID(S) ]] Where: - First(X,Y) indicates a truncation of "Y" data so that only the first "X" bits remain to be used. - Hash is a secure cryptographic function. - Ks is IKEv2 session key. - IID(C) = (C)'s IP address interface identifier - IID(S) = (S)'s IP address interface identifier - "|" (concatenation): indicates bytewise concatenation, as in A | B. This concatenation requires that all of the octets of the datum A appear first in the result, followed by all of the octets Haddad, et al. Expires January 2, 2008 [Page 6] Internet-Draft Location Authentication July 2007 of the datum B. - IID(C) | IID(S) = Hint (H) 2. Upon receiving a valid PRR message, AR(S) starts its mission by performing a "prefix lookup" using (C)'s 64-bit prefix, in order to learn the corresponding IP address and public key of AR(C) (denoted Kpc). It follows that the result of a prefix lookup MUST return the public key and the IP address of the router, which is advertising the queried prefix. Note that it may be useful for AR(S) to store AR(C) parameters for a limited amount of time. 3. After retrieving AR(C)'s IP address and public key, AR(S) sends an "On_Link_Presence_Request" (OLPR) message to AR(C), which carries (C)'s 64-bit interface identifier (IID), (S)'s 64-bit prefix and a 64-bit nonce. The IP destination address used in the OLPR message is the one sent to AR(S) in response to its query related to (C)'s prefix. The OLPR message MUST be authenticated with Ksh and signed with AR(S) private key. 4. Upon receiving an OLPR message, AR(C) starts the validation procedure by performing an (S)'s prefix look up in order to fetch the corresponding IP address(es) and public key(s) (we call it Kps). After that, AR(C) checks the validity of the IP source address used in the OLPR message. This is followed by checking the requested IID presence on the link. For this purpose, AR(C) SHOULD use the neighbor discovery protocol (described in [NDP]) and SHOULD insert the hint (H) in the corresponding message (i.e., in a new option). Finally, AR(C) MUST authenticate (or sign) the ND message before sending it (note that the message may be sent only to (C) and in this case, it can be authenticated with the shared secret obtained from running OptiSeND between AR(C) and (C)). 5. When (C) detects the hint in the ND message, it replies by sending Ksh to AR(C). For this purpose, Ksh is inserted in an encrypted option carried by an authenticated ND message sent to AR(C). 6. After receiving a valid ND message from (C), AR(C) decrypts Ksh and uses it to check the authenticity of the OLPR message. If the message is valid, then AR(C) proceeds to check the signature using AR(S)'s Kps, then sends back an "On_Link_Presence_Confirmation (OLPC)" message to AR(S). The OLPC message SHOULD carry (H) and the nonce sent in the OLPR message. In addition, the OLPC message MUST be authenticated with Ksh and signed with AR(C) private key. Haddad, et al. Expires January 2, 2008 [Page 7] Internet-Draft Location Authentication July 2007 However, if AR(C) does not get any valid reply (i.e., a message from (C) carrying Ksh), then it MUST send an "On_link_Prefix_Denial (OLPD)" message to AR(S). It follows that the OLPD message cannot be authenticated and in this case, it MUST carry the hint and the nonce sent in the OLPR message and MUST be signed with AR(C) private key only. 7. After checking the validity of OLPC/OLPD, AR(S) notifies (S) about the success/failure of its PRR message. This is done by sending a "Prefix_Reachability_Acknowledgment (PRA)" message to (S). The PRA message MUST be signed with AR(S) private key or authenticated with a shared secret between AR(S) and (S). The OLPD message is reflected in the PRA message by setting the "Alert" (A) bit. Following receipt of a valid PRA message, (S) can decide whether to pursue or not the data exchange with (C). The PRD procedure can be repeated periodically during the data exchange between the two endpoints and/or upon receiving a mobility signaling message indicating a switch made by (C) to another network or when switching to another interface. For this purpose, refreshing Ksh is required in each location authentication procedure. To this end, one way would be to add a counter in the formula used to generate Ksh. For instance, we could do: Ksh = First[ 128, Hash[ Hash(Ks) | IID(C) | IID(S) | COUNT ] ] Where COUNT is equal to zero on the first PRD, then its value is increased by 1 (or more) for each new run. This also means that the new value SHOULD be sent in the signaling. Haddad, et al. Expires January 2, 2008 [Page 8] Internet-Draft Location Authentication July 2007 5. New Options and Messages Formats The PRD protocol introduces 4 new messages and one new option which are TBD. Haddad, et al. Expires January 2, 2008 [Page 9] Internet-Draft Location Authentication July 2007 6. Security Considerations This memo introduces a new protocol, which aims to detect and thwart certain MiTM misbehavior. Hence, the main goal is to improve the detection and defense capabilities on both sides of the two communicating endpoints. If implemented correctly, in its current form and to the best of our knowledge, the PRD protocol does not introduce nor increase any new/existing security threats. It should be noted however, that the presence of a nonce in the OLPD message is highly recommended in order to avoid launching a DoS attack on AR(S). Haddad, et al. Expires January 2, 2008 [Page 10] Internet-Draft Location Authentication July 2007 7. Acknowledgments Authors would like to thank Pekka Nikander, Rolf Blom, Andras Mehes and Yuri Ismailov for their valuable input. Haddad, et al. Expires January 2, 2008 [Page 11] Internet-Draft Location Authentication July 2007 8. References 8.1. Normative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3792, March 2005. [HIP] Moskowitz, B., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Internet Draft, draft-ietf-hip-base-07.txt, February 2007. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", Internet Draft, draft-ietf-ipv6-2461bis-11.txt, March 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. 8.2. Informative References [OpSeND] Haddad, W., Krishnan, S., Choi, J., and J. Laganier, "Secure Neighbor Discovery (SeND) Optimizations: The OptiSeND Protocol", Internet Draft, draft-haddad-optimizing-send-00.txt, July 2007. [SAVA] Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I. Williams, "Source Address Verification Architecture Problem Statement", Internet Draft, draft-sava-problem-statement-00.txt, February 2007. [SIDR] Barnes, R. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Internet Draft, draft-ietf-sidr-arch-00.txt, January 2007. Haddad, et al. Expires January 2, 2008 [Page 12] Internet-Draft Location Authentication July 2007 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 Christian Vogt Ericsson Research Nomadic Lab Jorvas FI-02420 Finland Phone: +358 9 299 1 Email: Christian.Vogt@ericsson.com Haddad, et al. Expires January 2, 2008 [Page 13] Internet-Draft Location Authentication July 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). Haddad, et al. Expires January 2, 2008 [Page 14]