idnits 2.17.00 (12 Aug 2021) /tmp/idnits34918/draft-sheffer-ipsecme-secure-beacon-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2009) is 4710 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 194, but not defined == Missing Reference: 'TBD-BY-IANA1' is mentioned on line 257, but not defined == Missing Reference: 'TBD-BY-IANA2' is mentioned on line 262, but not defined ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: draft-ietf-mip4-vpn-problem-solution has been published as RFC 5265 -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Y. Nir 4 Intended status: Experimental Check Point 5 Expires: December 23, 2009 June 21, 2009 7 Secure Beacon: Securely Detecting a Trusted Network 8 draft-sheffer-ipsecme-secure-beacon-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 23, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 Remote access clients, in particular IPsec-based ones, are heavily 57 deployed in enterprise environments. In many enterprises the 58 security policy allows remote-access clients to switch to unprotected 59 operation when entering the trusted network. This document specifies 60 a method that lets a client detect this situation in a secure manner, 61 with the help of a security gateway. We propose a minor extension to 62 IKEv2 to achieve this goal. 64 Table of Contents 66 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. Client Mobility . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. Alternative Solutions . . . . . . . . . . . . . . . . . . 4 71 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Extending IKE for Secure Network Detection . . . . . . . . 4 73 3.1.1. The IKE_SA_INIT Exchange . . . . . . . . . . . . . . . 5 74 3.1.2. The IKE_AUTH Exchange . . . . . . . . . . . . . . . . 5 75 3.2. IKE Notify Payloads . . . . . . . . . . . . . . . . . . . 6 76 3.2.1. SECURE_NETWORK_DETECT . . . . . . . . . . . . . . . . 6 77 3.2.2. SECURE_NETWORK_DETECTED . . . . . . . . . . . . . . . 6 78 3.3. Detecting Movement . . . . . . . . . . . . . . . . . . . . 6 79 3.4. The Gateway's Decision . . . . . . . . . . . . . . . . . . 7 80 3.5. Client Security Policy . . . . . . . . . . . . . . . . . . 7 81 4. Interoperation with MOBIKE . . . . . . . . . . . . . . . . . . 7 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 7.1. draft-sheffer-ipsecme-secure-beacon-00 . . . . . . . . . . 9 86 7.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 7.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 7.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 7.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 96 1. Requirements Notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Introduction 104 The IKE and IPsec protocols are often used for remote-access clients. 105 IKE version 2 [RFC4306] provides enhanced support for remote-access 106 clients through the use of EAP. In many cases, IPsec clients need to 107 be "turned off" when the client roams into the internal, or "trusted" 108 network of an enterprise. This operation is very sensitive, since an 109 adversary may use this mechanism to force the client to send 110 unprotected packets into the network. This document defines an 111 extension to IKEv2 where the client contacts a trusted gateway, the 112 gateway detects that the client is located in a trusted network, and 113 delivers an indication to the client in a secure manner. An 114 important property of this protocol is that the exchange may 115 terminate early, if the client and the server agree that IPsec is not 116 required; otherwise the protocol will "fall through" into a standard 117 IKEv2 exchange, generating IKE and Child security associations. 119 Unfortunately at the time of writing, there is no IETF work group 120 chartered with IPsec. We encourage discussion of this draft on the 121 IPsec mailing list, https://www1.ietf.org/mailman/listinfo/ipsec. 123 2.1. Goals 125 The proposed protocol should fulfill the following goals. 126 o Security, in particular the protocol should not adversely affect 127 the security of IKE. 128 o Robustness: the protocol should fall back into a full IKE exchange 129 if any error is detected. 130 o Performance: minimize the number of exchanges and the CPU effort 131 expanded, whether the client is in the trusted or untrusted 132 network. 133 o Usability: the user should not be required to perform any action 134 unless this is required for security. We avoid sending the 135 client's identity, because this normally requires input from the 136 user. 137 o Simplicity: the protocol should deal with the case of "simple" 138 networks, meaning networks where the internal network is wholly 139 trusted. It does not need to cover more complex topologies. 140 o Extensibility: however, the base protocol can be extended, e.g. to 141 handle more complex networks. 143 2.2. Client Mobility 145 Client mobility in IKEv2 is defined using the MOBIKE protocol 146 extension, [RFC4555]. Section 4 below specifies how the Secure 147 Beacon solution coexists with MOBIKE. 149 2.3. Alternative Solutions 151 There are several alternatives for providing the functionality 152 discussed here. 153 o Several proposals related to Mobile IP, such as 154 [I-D.ietf-mip4-vpn-problem-solution], rely on secure connectivity 155 to the Home Agent, which is assumed to be in the trusted network. 156 This solution obviously can only be applied in a Mobile IP 157 setting. 158 o Some proprietary solutions rely on secure connectivity to other 159 "internal" hosts, for example the Windows Domain Controller. 160 o Another solution we have considered is to open a dedicated, short- 161 lived TLS connection into the security gateway. This would enable 162 the client to authenticate the gateway. However an IPsec gateway 163 should not be assumed to implement TLS. 164 o Lastly, we considered a new protocol, possibly derived from IKE. 165 A separate protocol offers modularity as its main benefit. 166 However we have chosen to reuse IKE itself, where the exchange can 167 be completed as a full IKE exchange. This results in fewer 168 exchanges, and possibly in a simpler implementation. 170 3. Protocol Details 172 The following sections describe the protocol, first at the exchange 173 level and then at the payload level. Following that, we discuss two 174 central issues: how the client detects that it has moved, so that 175 this protocol can be run, and how the gateway can make the decision 176 whether the client is in the trusted or untrusted network. 178 3.1. Extending IKE for Secure Network Detection 180 To summarize, we add an IKE notification to message #1 of the 181 protocol, and another to message #2. However, the protocol is only 182 terminated after the initiator has authenticated the responder, i.e. 183 after message #4. It is important to note that the initiator's 184 identity may not be authenticated if the protocol is terminated 185 early. 187 3.1.1. The IKE_SA_INIT Exchange 189 The IKE_SA_INIT exchange is modified as follows: 191 Initiator Responder 192 ----------- ----------- 193 HDR, SAi1, KEi, Ni, N1 --> 194 <-- HDR, SAr1, KEr, Nr, N2, [CERTREQ] 196 All payloads, with the exception of the notifications, have their 197 usual semantics. The first notification, N1, is of type 198 SECURE_NETWORK_DETECT. It denotes to the responder that it SHOULD 199 respond with a second notification (N2), which is of type 200 SECURE_NETWORK_DETECTED. Both notifications are defined in 201 Section 3.2. Note that both notifications are sent in the clear. 203 Following the first exchange, there are three options: 204 o If there is no response after the normal retransmission period, 205 the client SHOULD assume it is on an untrusted network, and is 206 experiencing connectivity problems. For example, the IKE port may 207 be blocked. 208 o Otherwise, a response was received. If N2 is not received, or if 209 it is received but explicitly specifies that the initiator is in 210 an untrusted network, the protocol continues according to standard 211 IKE rules. This would be the case if the responder does not 212 understand the SECURE_NETWORK_DETECT notification. 213 o If N2 indicates that the initiator is in a trusted network, the 214 protocol continues as detailed in Section 3.1.2 below. 216 3.1.2. The IKE_AUTH Exchange 218 The initiator now responds with a truncated IKE_AUTH exchange: 220 HDR, SK {[IDi, CERT,] [CERTREQ,] [IDr,] [AUTH]} --> 222 The initiator sends the AUTH payload only if it can be authenticated 223 in message #2, i.e. if it uses a shared secret or certificate, rather 224 than EAP. Even if the initiator normally authenticates using one of 225 these methods, it MAY omit both IDi and AUTH, in order to avoid user 226 interaction. If AUTH is included, then the responder MUST 227 authenticate the initiator. 229 The responder replies with: 231 <-- HDR, SK {IDr, [CERT,] AUTH} 233 The initiator MUST now validate the identity of the responder as 234 defined in [RFC4306], and following that, MUST terminate the 235 protocol. Obviously in this case, no Child SA is created and 236 therefore no IPsec-protected traffic will be sent. Moreover, no 237 long-term IKE SA is created, and both parties SHOULD delete their IKE 238 SAs. The initiator SHOULD send an Informational exchange containing 239 a Delete payload for the IKE SA. The responder should regard a 240 persistent IKE SA where a secure network has been detected as 241 anomalous and audit their existence. The responder MUST NOT allow 242 any Create Child SA exchanges based on such an IKE SA. 244 See also Section 3.5 regarding implications on the client's security 245 policy. 247 It is RECOMMENDED that the client display a message to the user at 248 this point, announcing that it has moved into unprotected mode. 250 3.2. IKE Notify Payloads 252 We define two new notify payload types, SECURE_NETWORK_DETECT and 253 SECURE_NETWORK_DETECTED. 255 3.2.1. SECURE_NETWORK_DETECT 257 This notification type has the value [TBD-BY-IANA1]. It contains no 258 data. 260 3.2.2. SECURE_NETWORK_DETECTED 262 This notification type has the value [TBD-BY-IANA2]. 264 This notify payload includes a single 1-octet data item. It has the 265 value 0 if the responder believes that the initiator is coming from 266 an untrusted network, or if the responder cannot determine where the 267 initiator is coming from. It has the value 1 if the responder 268 believes that the initiator is coming from a trusted network. 270 Implementations MAY include additional data in this notify payload, 271 however this usage SHOULD be signaled with a Vendor ID payload. Such 272 additional data MUST be ignored by the receiver if not understood. 274 3.3. Detecting Movement 276 Mobility detection is outside the scope of this document. The 277 procedures involved are best described in [RFC4436] for IPv4. The 278 DNA procedures SHOULD be followed, so that the client can employ the 279 mechanism defined here whenever it suspects that it has moved into a 280 new network, particularly from a trusted to an untrusted network. 282 3.4. The Gateway's Decision 284 The gateway MUST be configured to make a correct decision regarding 285 the client's location. Typically, the gateway would only detect 286 clients connecting through the trusted network if their IKE packets 287 arrive from a trusted physical network interface. Determining which 288 network or network type is considered trusted is left to local 289 policy. 291 It is RECOMMENDED that the gateway indicate an untrusted network, if 292 it detects that the client is behind a NAT. See Section 6 for 293 rationale. 295 3.5. Client Security Policy 297 If the client sends the SECURE_NETWORK_DETECT notification and does 298 not receive an indication of a trusted network, it SHOULD NOT change 299 its existing SPD and SPD Cache. 301 If the client receives the SECURE_NETWORK_DETECTED notification 302 indicating a trusted network, it should alter its behavior as 303 follows. 305 The client SHOULD create BYPASS entries in the SPD Cache for all 306 PROTECT entries in the SPD which are associated with the peer 307 gateway. An entry is said to be associated with a peer gateway if it 308 is a transport mode entry and the remote address is the peer gateway 309 address, or if it is a tunnel mode entry, and the remote tunnel 310 address is the peer gateway address. 312 The above SPD Cache entries MUST be reset (flushed) whenever the 313 client detects that it has moved from one network attachment to 314 another. See Section 3.3. 316 IKEv2 allows the client to populate the SPD Cache dynamically based 317 on the INTERNAL_IPv*_SUBNET attributes in the configuration payload 318 (see section 6.3 in IKEv2 Clarifications [RFC4718]). However, since 319 the client does not reach this state, depending on its static SPD 320 configuration, such a client might effectively create a BYPASS entry 321 for the entire IP address space. 323 4. Interoperation with MOBIKE 325 The client MAY include the SECURE_NETWORK_DETECT notification in any 326 Informational exchange that contains an UPDATE_SA_ADDRESSES 327 notification. 329 By this time, the client has already determined that the gateway 330 supports both MOBIKE and the Secure Beacon extension. The gateway 331 MUST respond with a SECURE_NETWORK_DETECTED notification in the 332 response to this Informational exchange. 334 If the gateway's response specifies that the client is in a trusted 335 network: 336 o The gateway MUST NOT attempt a return routability check, if such a 337 check would have normally been required. 338 o Both client and gateway MUST tear down the existing IKE SA, and 339 terminate the IKE protocol. The client SHOULD send an 340 Informational exchange containing a Delete payload for the IKE SA. 341 o It is RECOMMENDED that the client display a message to the user at 342 this point, announcing that it has moved into unprotected mode. 343 o The next time the client detects that it has moved, it SHOULD re- 344 initiate an IKE exchange. 346 5. IANA Considerations 348 This document does not create any new namespaces to be maintained by 349 IANA, but it requires new values in namespaces that have been defined 350 in the IKEv2 base specification. 352 This document defines several new IKEv2 notifications whose values 353 are to be allocated from the "IKEv2 Notify Message Types" namespace. 355 Notify Messages - Error Types Value 356 ----------------------------- ----- 357 None 359 Notify Messages - Status Types Value 360 ------------------------------ ----- 361 SECURE_NETWORK_DETECT TBD-BY-IANA1 (16396..40959) 362 SECURE_NETWORK_DETECTED TBD-BY-IANA2 (16396..40959) 364 6. Security Considerations 366 The proposed solution needs to be analyzed carefully, since it may 367 cause a host to switch from protected to unprotected communication. 368 Following are the threats that we have identified. 369 1. The notifications are sent in the clear. A passive attacker will 370 learn whether the responder is receiving traffic over a trusted 371 or untrusted interface. This is information that the attacker is 372 probably able to obtain otherwise. 374 2. An active attacker may be able to change either or both 375 notifications. The first notification N1 does not carry any 376 data, so it can at worst be deleted. In this case the protocol 377 will revert to normal IKE. 378 3. An active attacker's change to the N2 notification (or deletion 379 of N2) will be detected since IKE message #2 is authenticated and 380 integrity-protected. Therefore this attack is only equivalent to 381 a DoS attack on IKE. Moreover, the protocol is "fail safe" since 382 any detected failures or attacks will at worst result in the 383 client using a secure channel where one is not required by 384 policy. 385 4. This protocol can be defeated by an active attacker who can 386 inject packets into the trusted network and relay the responses 387 to such packets back into the untrusted network. Such an 388 attacker will be able to cheat the client into believing that it 389 is on the trusted network. We believe we do not have to address 390 this threat. 391 5. This protocol MUST NOT be used if the network can change the path 392 between the client and the security gateway without the client's 393 awareness, causing its security properties to change. That is, 394 if the network can route traffic sometimes over a trusted path 395 and sometimes over an untrusted one, without notifying the end- 396 point. Such a situation might be possible in incorrectly 397 configured Mobile IP deployments, e.g. where the same Home Agent 398 is shared between a trusted Wi-Fi access network and an untrusted 399 one, and where the IPsec layer is not informed of the 400 connectivity changes. 401 6. There are rare cases when a client is collocated with a NAT. One 402 such case is a client implemented within a software virtual 403 machine. In such cases the client is likely to remain unaware 404 when moving from a trusted to an untrusted network. Therefore we 405 recommend (Section 3.4) to always indicate an untrusted network 406 to clients behind NAT. 408 7. Change Log 410 [[ Note to RFC Editor: please remove this section before publication. 411 ]] 413 7.1. draft-sheffer-ipsecme-secure-beacon-00 415 Renamed draft. 417 7.2. -03 419 Intended status changed to Experimental. 421 7.3. -02 423 Minor editorial changes. 425 7.4. -01 427 Added a section on the client's security policy, per [RFC4301]. 428 Added discussion of the interaction with MOBIKE. Added treatment of 429 client behind NAT. 431 7.5. -00 433 Initial version. 435 8. Acknowledgements 437 We would like to thank Ariel Shaqed for his many useful comments. 438 Thanks to Steve Kent for helping to clarify security policy issues. 440 9. References 442 9.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 448 Internet Protocol", RFC 4301, December 2005. 450 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 451 RFC 4306, December 2005. 453 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 454 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 456 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 457 (MOBIKE)", RFC 4555, June 2006. 459 9.2. Informative References 461 [I-D.ietf-mip4-vpn-problem-solution] 462 Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across 463 IPsec-based VPN Gateways", 464 draft-ietf-mip4-vpn-problem-solution-05 (work in 465 progress), March 2008. 467 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 468 Implementation Guidelines", RFC 4718, October 2006. 470 Authors' Addresses 472 Yaron Sheffer 473 Check Point Software Technologies Ltd. 474 5 Hasolelim st. 475 Tel Aviv 67897 476 Israel 478 Email: yaronf@checkpoint.com 480 Yoav Nir 481 Check Point Software Technologies Ltd. 482 5 Hasolelim st. 483 Tel Aviv 67897 484 Israel 486 Email: ynir@checkpoint.com