idnits 2.17.1 draft-haddad-prefix-reachability-detection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2009) is 5297 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-ikev2bis-05 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-08 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Source Address Validation W. Haddad 3 Improvements (SAVI) M. Naslund 4 Internet-Draft C. Vogt 5 Intended status: Standards Track Ericsson 6 Expires: April 28, 2010 October 25, 2009 8 Enabling Source Address Verification via Prefix Reachability Detection 9 draft-haddad-prefix-reachability-detection-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 28, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 In this memo, we introduce an approach called "Prefix Reachability 48 Detection", which aims to address certain man-in-the middle 49 misbehavior problems and enable a location-based authentication. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . 4 55 3. Motivation and Assumptions . . . . . . . . . . . . . . . . . . 5 56 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 57 5. New Options and Messages Formats . . . . . . . . . . . . . . . 9 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 65 1. Introduction 67 In this memo, we introduce an approach called "Prefix Reachability 68 Detection (PRD)", which aims to address certain man-in-the middle 69 (MiTM) misbehavior problems on the IP layer and enable a location- 70 based authentication. A direct consequence of applying the PRD 71 approach is a source address verification mechanism, which can also 72 be used in a mobile and multihomed environment. 74 The main components for applying the PRD protocol are a secure and 75 trustable "prefix routing lookup" mechanism and a secure on-demand 76 query/response between the communicating endpoints and their first 77 hop routers. 79 2. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Motivation and Assumptions 87 The motivation behind this work stems from the need for an efficient 88 and scalable solution to thwart MiTM misbehavior. In fact, a MiTM 89 misbehavior can manifest itself in different aspects, which include 90 unwanted traffic, impersonation, identity theft, denial-of service 91 (DoS). All these aspects can target a network and/or a particular 92 node but they share the same disruptive and destructive goals. They 93 also have one common feature reflected by the alarming and steadily 94 increasing frequency of their occurrence. Consequently, there is an 95 urgent need to address this problem to avoid what could be (very) 96 unpleasant real-world side-effects. 98 Our goal is to provide a solution, which can protect against these 99 different aspects by enabling a source address verification mechanism 100 and at in parallel, offer a set of attributes which can significantly 101 improve the security and the overall efficiency of different types of 102 new and existing solutions. These attributes can be seen as 103 consequences, which fall beyond addressing the SAVI problem. 105 In order to achieve our goal, we make the following assumptions: 107 - Existence of a secure and trustable mechanism, which enables at 108 least a particular set/class of routers to fetch security credentials 109 (i.e., using a third entity) of other routers belonging to the same 110 set. Such mechanism can be based for example, on the ongoing work 111 related to supporting secure Internet routing [I-D.ietf-sidr-arch]. 113 - Existence of secure and trustable links between each endpoint and 114 the first hop router. Note that this does not really impose new 115 requirements and has already been addressed in [RFC3971]. 117 4. Protocol Overview 119 The suggested approach enables one endpoint to check the topological 120 location of the other endpoint, which maps correctly to the prefix 121 claimed in their IP address. Such procedure is also referred to by 122 "location authentication". 124 The PRD protocol is performed in parallel with running a key exchange 125 protocol, e.g., [I-D.ietf-ipsecme-ikev2bis] or [RFC4423]. In the 126 following, we consider the classic scenario where a client (C) is 127 establishing an IKEv2 session with a server (S) and we delegate to 128 (S) the task of triggering the PRD protocol. 130 In its most generic form, the PRD protocol consists on executing (in 131 order) the following steps: 133 1. After completing the IKEv2 exchange, (S) requests from its first 134 hop router (we call it AR(S)) to perform a prefix reachability 135 detection, i.e., location authentication, on (C)'s IP address. 136 For this purpose, (S) sends a "Prefix_Reachability_Request (PRR)" 137 message to AR(S), which carries a secret (called Ksh) and (C)'s 138 IP address. Ksh is derived from the hash of IKEv2 session key 139 (Ks) and a hint (H). The PRR message MUST be signed with (C)'s 140 CGA private key (as described in [RFC3972]) and the option 141 carrying Ksh MUST be encrypted with AR(S) public key. 143 (C) and (S) MUST use the same method to derive Ksh. This method 144 SHOULD be: 146 Ksh = First[ 128, Hash[ Hash(Ks) | IID(C) | IID(S) ]] 148 Where: 150 - First(X,Y) indicates a truncation of "Y" data so that only the 151 first "X" bits remain to be used. 152 - Hash is a secure cryptographic function. 153 - Ks is IKEv2 session key. 154 - IID(C) = (C)'s IP address interface identifier 155 - IID(S) = (S)'s IP address interface identifier 156 - "|" (concatenation): indicates bytewise concatenation, as in A 157 | B. This concatenation requires that all of the octets of the 158 datum A appear first in the result, followed by all of the octets 159 of the datum B. 160 - IID(C) | IID(S) = Hint (H) 162 2. Upon receiving a valid PRR message, AR(S) starts its mission by 163 performing a "prefix lookup" using (C)'s 64-bit prefix, in order 164 to learn the corresponding IP address and public key of AR(C) 165 (denoted Kpc). It follows that the result of a prefix lookup 166 MUST return the public key and the IP address of the router, 167 which is advertising the queried prefix. Note that it may be 168 useful for AR(S) to store AR(C) parameters for a limited amount 169 of time. 171 3. After retrieving AR(C)'s IP address and public key, AR(S) sends 172 an "On_Link_Presence_Request" (OLPR) message to AR(C), which 173 carries (C)'s 64-bit interface identifier (IID), (S)'s 64-bit 174 prefix and a 64-bit nonce. The IP destination address used in 175 the OLPR message is the one sent to AR(S) in response to its 176 query related to (C)'s prefix. The OLPR message MUST be 177 authenticated with Ksh and signed with AR(S) private key. 179 4. Upon receiving an OLPR message, AR(C) starts the validation 180 procedure by performing an (S)'s prefix look up in order to fetch 181 the corresponding IP address(es) and public key(s) (we call it 182 Kps). After that, AR(C) checks the validity of the IP source 183 address used in the OLPR message. This is followed by checking 184 the requested IID presence on the link. For this purpose, AR(C) 185 SHOULD use the neighbor discovery protocol (described in 186 [RFC4861]) and SHOULD insert the hint (H) in the corresponding 187 message (i.e., in a new option). Finally, AR(C) MUST 188 authenticate (or sign) the ND message before sending it (note 189 that the message may be sent only to (C) and in this case, it can 190 be authenticated with the shared secret obtained from running 191 OptiSeND between AR(C) and (C)). 193 5. When (C) detects the hint in the ND message, it replies by 194 sending Ksh to AR(C). For this purpose, Ksh is inserted in an 195 encrypted option carried by an authenticated ND message sent to 196 AR(C). 198 6. After receiving a valid ND message from (C), AR(C) decrypts Ksh 199 and uses it to check the authenticity of the OLPR message. If 200 the message is valid, then AR(C) proceeds to check the signature 201 using AR(S)'s Kps, then sends back an 202 "On_Link_Presence_Confirmation (OLPC)" message to AR(S). The 203 OLPC message SHOULD carry (H) and the nonce sent in the OLPR 204 message. In addition, the OLPC message MUST be authenticated 205 with Ksh and signed with AR(C) private key. 207 However, if AR(C) does not get any valid reply (i.e., a message 208 from (C) carrying Ksh), then it MUST send an 209 "On_link_Prefix_Denial (OLPD)" message to AR(S). It follows that 210 the OLPD message cannot be authenticated and in this case, it 211 MUST carry the hint and the nonce sent in the OLPR message and 212 MUST be signed with AR(C) private key only. 214 7. After checking the validity of OLPC/OLPD, AR(S) notifies (S) 215 about the success/failure of its PRR message. This is done by 216 sending a "Prefix_Reachability_Acknowledgment (PRA)" message to 217 (S). The PRA message MUST be signed with AR(S) private key or 218 authenticated with a shared secret between AR(S) and (S). The 219 OLPD message is reflected in the PRA message by setting the 220 "Alert" (A) bit. 221 Following receipt of a valid PRA message, (S) can decide whether 222 to pursue or not the data exchange with (C). 224 The PRD procedure can be repeated periodically during the data 225 exchange between the two endpoints and/or upon receiving a mobility 226 signaling message indicating a switch made by (C) to another network 227 or when switching to another interface. For this purpose, refreshing 228 Ksh is required in each location authentication procedure. To this 229 end, one way would be to add a counter in the formula used to 230 generate Ksh. For instance, we could do: 232 Ksh = First[ 128, Hash[ Hash(Ks) | IID(C) | IID(S) | COUNT ] ] 234 Where COUNT is equal to zero on the first PRD, then its value is 235 increased by 1 (or more) for each new run. This also means that the 236 new value SHOULD be sent in the signaling. 238 5. New Options and Messages Formats 240 The PRD protocol introduces 4 new messages and one new option which 241 are TBD. 243 6. Security Considerations 245 This memo introduces a new protocol, which aims to detect and thwart 246 certain MiTM misbehavior. Hence, the main goal is to improve the 247 detection and defense capabilities on both sides of the two 248 communicating endpoints. If implemented correctly, in its current 249 form and to the best of our knowledge, the PRD protocol does not 250 introduce nor increase any new/existing security threats. It should 251 be noted however, that the presence of a nonce in the OLPD message is 252 highly recommended in order to avoid launching a DoS attack on AR(S). 254 7. Acknowledgments 256 Authors would like to thank Pekka Nikander, Rolf Blom, Andras Mehes 257 and Yuri Ismailov for their valuable input. 259 8. References 261 8.1. Normative References 263 [I-D.ietf-ipsecme-ikev2bis] 264 Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 265 "Internet Key Exchange Protocol: IKEv2", 266 draft-ietf-ipsecme-ikev2bis-05 (work in progress), 267 October 2009. 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 273 Neighbor Discovery (SEND)", RFC 3971, March 2005. 275 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 276 RFC 3972, March 2005. 278 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 279 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 280 September 2007. 282 8.2. Informative References 284 [I-D.ietf-sidr-arch] 285 Lepinski, M. and S. Kent, "An Infrastructure to Support 286 Secure Internet Routing", draft-ietf-sidr-arch-08 (work in 287 progress), July 2009. 289 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 290 (HIP) Architecture", RFC 4423, May 2006. 292 Authors' Addresses 294 Wassim Michel Haddad 295 Ericsson 296 6210 Spine Rd 297 Boulder, CO 80301 298 USA 300 Phone: +1 3034736963 301 Email: Wassim.Haddad@ericsson.com 303 Mats Naslund 304 Ericsson 305 Torshamnsgatan 23 306 SE-164 80 Stockholm 307 Sweden 309 Phone: +46 8 58533739 310 Email: Mats.Naslund@ericsson.com 312 Christian Vogt 313 Ericsson 314 200 Holger Way 315 San Jose, CA 95134 316 United States 318 Email: Christian.Vogt@ericsson.com