Source Address Validation W. Haddad Improvements (SAVI) M. Naslund Internet-Draft C. Vogt Intended status: Standards Track Ericsson Expires: April 28, 2010 October 25, 2009 Enabling Source Address Verification via Prefix Reachability Detection draft-haddad-prefix-reachability-detection-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Haddad, et al. Expires April 28, 2010 [Page 1] Internet-Draft Location Authentication October 2009 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 Haddad, et al. Expires April 28, 2010 [Page 2] Internet-Draft Location Authentication October 2009 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 April 28, 2010 [Page 3] Internet-Draft Location Authentication October 2009 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 [RFC2119]. Haddad, et al. Expires April 28, 2010 [Page 4] Internet-Draft Location Authentication October 2009 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 SAVI problem. 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 related to supporting secure Internet routing [I-D.ietf-sidr-arch]. - 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 [RFC3971]. Haddad, et al. Expires April 28, 2010 [Page 5] Internet-Draft Location Authentication October 2009 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., [I-D.ietf-ipsecme-ikev2bis] or [RFC4423]. 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 [RFC3972]) and the option carrying Ksh MUST be encrypted with AR(S) public key. (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 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) Haddad, et al. Expires April 28, 2010 [Page 6] Internet-Draft Location Authentication October 2009 (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 [RFC4861]) 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. 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. Haddad, et al. Expires April 28, 2010 [Page 7] Internet-Draft Location Authentication October 2009 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 April 28, 2010 [Page 8] Internet-Draft Location Authentication October 2009 5. New Options and Messages Formats The PRD protocol introduces 4 new messages and one new option which are TBD. Haddad, et al. Expires April 28, 2010 [Page 9] Internet-Draft Location Authentication October 2009 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 April 28, 2010 [Page 10] Internet-Draft Location Authentication October 2009 7. Acknowledgments Authors would like to thank Pekka Nikander, Rolf Blom, Andras Mehes and Yuri Ismailov for their valuable input. Haddad, et al. Expires April 28, 2010 [Page 11] Internet-Draft Location Authentication October 2009 8. References 8.1. Normative References [I-D.ietf-ipsecme-ikev2bis] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol: IKEv2", draft-ietf-ipsecme-ikev2bis-05 (work in progress), October 2009. [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. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 8.2. Informative References [I-D.ietf-sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-08 (work in progress), July 2009. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. Haddad, et al. Expires April 28, 2010 [Page 12] Internet-Draft Location Authentication October 2009 Authors' Addresses Wassim Michel Haddad Ericsson 6210 Spine Rd Boulder, CO 80301 USA Phone: +1 3034736963 Email: Wassim.Haddad@ericsson.com Mats Naslund Ericsson Torshamnsgatan 23 SE-164 80 Stockholm Sweden Phone: +46 8 58533739 Email: Mats.Naslund@ericsson.com Christian Vogt Ericsson 200 Holger Way San Jose, CA 95134 United States Email: Christian.Vogt@ericsson.com Haddad, et al. Expires April 28, 2010 [Page 13]