idnits 2.17.1 draft-sheffer-ipsec-secure-beacon-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. 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 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 (January 21, 2008) is 5933 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 179, but not defined == Missing Reference: 'TBD-BY-IANA1' is mentioned on line 242, but not defined == Missing Reference: 'TBD-BY-IANA2' is mentioned on line 247, but not defined ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-05) exists of draft-ietf-mip4-vpn-problem-solution-04 -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: July 24, 2008 January 21, 2008 7 Secure Beacon: Securely Detecting a Trusted Network 8 draft-sheffer-ipsec-secure-beacon-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 Remote access clients, in particular IPsec-based ones, are heavily 42 deployed in enterprise environments. In many enterprises the 43 security policy allows remote-access clients to switch to unprotected 44 operation when entering the trusted network. This document specifies 45 a method that lets a client detect this situation in a secure manner, 46 with the help of a security gateway. We propose a minor extension to 47 IKEv2 to achieve this goal. 49 Table of Contents 51 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Client Mobility . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Alternative Solutions . . . . . . . . . . . . . . . . . . 4 56 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Extending IKE for Secure Network Detection . . . . . . . . 4 58 3.1.1. The IKE_SA_INIT Exchange . . . . . . . . . . . . . . . 5 59 3.1.2. The IKE_AUTH Exchange . . . . . . . . . . . . . . . . 5 60 3.2. IKE Notify Payloads . . . . . . . . . . . . . . . . . . . 6 61 3.2.1. SECURE_NETWORK_DETECT . . . . . . . . . . . . . . . . 6 62 3.2.2. SECURE_NETWORK_DETECTED . . . . . . . . . . . . . . . 6 63 3.3. Detecting Movement . . . . . . . . . . . . . . . . . . . . 6 64 3.4. The Gateway's Decision . . . . . . . . . . . . . . . . . . 7 65 3.5. Client Security Policy . . . . . . . . . . . . . . . . . . 7 66 4. Interoperation with MOBIKE . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 Intellectual Property and Copyright Statements . . . . . . . . . . 12 81 1. Requirements Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Introduction 89 The IKE and IPsec protocols are often used for remote-access clients. 90 IKE version 2 [RFC4306] provides enhanced support for remote-access 91 clients through the use of EAP. In many cases, IPsec clients need to 92 be "turned off" when the client roams into the internal, or "trusted" 93 network of an enterprise. This operation is very sensitive, since an 94 adversary may use this mechanism to force the client to send 95 unprotected packets into the network. This document defines an 96 extension to IKEv2 where the client contacts a trusted gateway, the 97 gateway detects that the client is located in a trusted network, and 98 delivers an indication to the client in a secure manner. An 99 important property of this protocol is that the exchange may 100 terminate early, if the client and the server agree that IPsec is not 101 required; otherwise the protocol will "fall through" into a standard 102 IKEv2 exchange, generating IKE and Child security associations. 104 Unfortunately at the time of writing, there is no IETF work group 105 chartered with IPsec. We encourage discussion of this draft on the 106 IPsec mailing list, https://www1.ietf.org/mailman/listinfo/ipsec. 108 2.1. Goals 110 The proposed protocol should fulfill the following goals. 111 o Security, in particular the protocol should not adversely affect 112 the security of IKE. 113 o Robustness: the protocol should fall back into a full IKE exchange 114 if any error is detected. 115 o Performance: minimize the number of exchanges and the CPU effort 116 expanded, whether the client is in the trusted or untrusted 117 network. 118 o Usability: the user should not be required to perform any action 119 unless this is required for security. We avoid sending the 120 client's identity, because this normally requires input from the 121 user. 122 o Simplicity: the protocol should deal with the case of "simple" 123 networks, meaning networks where the internal network is wholly 124 trusted. It does not need to cover more complex topologies. 125 o Extensibility: however, the base protocol can be extended, e.g. to 126 handle more complex networks. 128 2.2. Client Mobility 130 Client mobility in IKEv2 is defined using the MOBIKE protocol 131 extension, [RFC4555]. Section 4 below specifies how the Secure 132 Beacon solution coexists with MOBIKE. 134 2.3. Alternative Solutions 136 There are several alternatives for providing the functionality 137 discussed here. 138 o Several proposals related to Mobile IP, such as 139 [I-D.ietf-mip4-vpn-problem-solution], rely on secure connectivity 140 to the Home Agent, which is assumed to be in the trusted network. 141 This solution obviously can only be applied in a Mobile IP 142 setting. 143 o Some proprietary solutions rely on secure connectivity to other 144 "internal" hosts, for example the Windows Domain Controller. 145 o Another solution we have considered is to open a dedicated, short- 146 lived TLS connection into the security gateway. This would enable 147 the client to authenticate the gateway. However an IPsec gateway 148 should not be assumed to implement TLS. 149 o Lastly, we considered a new protocol, possibly derived from IKE. 150 A separate protocol offers modularity as its main benefit. 151 However we have chosen to reuse IKE itself, where the exchange can 152 be completed as a full IKE exchange. This results in fewer 153 exchanges, and possibly in a simpler implementation. 155 3. Protocol Details 157 The following sections describe the protocol, first at the exchange 158 level and then at the payload level. Following that, we discuss two 159 central issues: how the client detects that it has moved, so that 160 this protocol can be run, and how the gateway can make the decision 161 whether the client is in the trusted or untrusted network. 163 3.1. Extending IKE for Secure Network Detection 165 To summarize, we add an IKE notification to message #1 of the 166 protocol, and another to message #2. However, the protocol is only 167 terminated after the initiator has authenticated the responder, i.e. 168 after message #4. It is important to note that the initiator's 169 identity may not be authenticated if the protocol is terminated 170 early. 172 3.1.1. The IKE_SA_INIT Exchange 174 The IKE_SA_INIT exchange is modified as follows: 176 Initiator Responder 177 ----------- ----------- 178 HDR, SAi1, KEi, Ni, N1 --> 179 <-- HDR, SAr1, KEr, Nr, N2, [CERTREQ] 181 All payloads, with the exception of the notifications, have their 182 usual semantics. The first notification, N1, is of type 183 SECURE_NETWORK_DETECT. It denotes to the responder that it SHOULD 184 respond with a second notification (N2), which is of type 185 SECURE_NETWORK_DETECTED. Both notifications are defined in 186 Section 3.2. Note that both notifications are sent in the clear. 188 Following the first exchange, there are three options: 189 o If there is no response after the normal retransmission period, 190 the client SHOULD assume it is on an untrusted network, and is 191 experiencing connectivity problems. For example, the IKE port may 192 be blocked. 193 o Otherwise, a response was received. If N2 is not received, or if 194 it is received but explicitly specifies that the initiator is in 195 an untrusted network, the protocol continues according to standard 196 IKE rules. This would be the case if the responder does not 197 understand the SECURE_NETWORK_DETECT notification. 198 o If N2 indicates that the initiator is in a trusted network, the 199 protocol continues as detailed in Section 3.1.2 below. 201 3.1.2. The IKE_AUTH Exchange 203 The initiator now responds with a truncated IKE_AUTH exchange: 205 HDR, SK {[IDi, CERT,] [CERTREQ,] [IDr,] [AUTH]} --> 207 The initiator sends the AUTH payload only if it can be authenticated 208 in message #2, i.e. if it uses a shared secret or certificate, rather 209 than EAP. Even if the initiator normally authenticates using one of 210 these methods, it MAY omit both IDi and AUTH, in order to avoid user 211 interaction. If AUTH is included, then the responder MUST 212 authenticate the initiator. 214 The responder replies with: 216 <-- HDR, SK {IDr, [CERT,] AUTH} 218 The initiator MUST now validate the identity of the responder as 219 defined in [RFC4306], and following that, MUST terminate the 220 protocol. Obviously in this case, no Child SA is created and 221 therefore no IPsec-protected traffic will be sent. Moreover, no 222 long-term IKE SA is created, and both parties SHOULD delete their IKE 223 SAs. The initiator SHOULD send an Informational exchange containing 224 a Delete payload for the IKE SA. The responder should regard a 225 persistent IKE SA where a secure network has been detected as 226 anomalous and audit their existence. The responder MUST NOT allow 227 any Create Child SA exchanges based on such an IKE SA. 229 See also Section 3.5 regarding implications on the client's security 230 policy. 232 It is RECOMMENDED that the client display a message to the user at 233 this point, announcing that it has moved into unprotected mode. 235 3.2. IKE Notify Payloads 237 We define two new notify payload types, SECURE_NETWORK_DETECT and 238 SECURE_NETWORK_DETECTED. 240 3.2.1. SECURE_NETWORK_DETECT 242 This notification type has the value [TBD-BY-IANA1]. It contains no 243 data. 245 3.2.2. SECURE_NETWORK_DETECTED 247 This notification type has the value [TBD-BY-IANA2]. 249 This notify payload includes a single 1-octet data item. It has the 250 value 0 if the responder believes that the initiator is coming from 251 an untrusted network, or if the responder cannot determine where the 252 initiator is coming from. It has the value 1 if the responder 253 believes that the initiator is coming from a trusted network. 255 Implementations MAY include additional data in this notify payload, 256 however this usage SHOULD be signaled with a Vendor ID payload. Such 257 additional data MUST be ignored by the receiver if not understood. 259 3.3. Detecting Movement 261 Mobility detection is outside the scope of this document. The 262 procedures involved are best described in [RFC4436] for IPv4. The 263 DNA procedures SHOULD be followed, so that the client can employ the 264 mechanism defined here whenever it suspects that it has moved into a 265 new network, particularly from a trusted to an untrusted network. 267 3.4. The Gateway's Decision 269 The gateway MUST be configured to make a correct decision regarding 270 the client's location. Typically, the gateway would only detect 271 clients connecting through the trusted network if their IKE packets 272 arrive from a trusted physical network interface. Determining which 273 network or network type is considered trusted is left to local 274 policy. 276 It is RECOMMENDED that the gateway indicate an untrusted network, if 277 it detects that the client is behind a NAT. See Section 6 for 278 rationale. 280 3.5. Client Security Policy 282 If the client sends the SECURE_NETWORK_DETECT notification and does 283 not receive an indication of a trusted network, it SHOULD NOT change 284 its existing SPD and SPD Cache. 286 If the client receives the SECURE_NETWORK_DETECTED notification 287 indicating a trusted network, it should alter its behavior as 288 follows. 290 The client SHOULD create BYPASS entries in the SPD Cache for all 291 PROTECT entries in the SPD which are associated with the peer 292 gateway. An entry is said to be associated with a peer gateway if it 293 is a transport mode entry and the remote address is the peer gateway 294 address, or if it is a tunnel mode entry, and the remote tunnel 295 address is the peer gateway address. 297 The above SPD Cache entries MUST be reset (flushed) whenever the 298 client detects that it has moved from one network attachment to 299 another. See Section 3.3. 301 IKEv2 allows the client to populate the SPD Cache dynamically based 302 on the INTERNAL_IPv*_SUBNET attributes in the configuration payload 303 (see section 6.3 in IKEv2 Clarifications [RFC4718]). However, since 304 the client does not reach this state, depending on its static SPD 305 configuration, such a client might effectively create a BYPASS entry 306 for the entire IP address space. 308 4. Interoperation with MOBIKE 310 The client MAY include the SECURE_NETWORK_DETECT notification in any 311 Informational exchange that contains an UPDATE_SA_ADDRESSES 312 notification. 314 By this time, the client has already determined that the gateway 315 supports both MOBIKE and the Secure Beacon extension. The gateway 316 MUST respond with a SECURE_NETWORK_DETECTED notification in the 317 response to this Informational exchange. 319 If the gateway's response specifies that the client is in a trusted 320 network: 321 o The gateway MUST NOT attempt a return routability check, if such a 322 check would have normally been required. 323 o Both client and gateway MUST tear down the existing IKE SA, and 324 terminate the IKE protocol. The client SHOULD send an 325 Informational exchange containing a Delete payload for the IKE SA. 326 o It is RECOMMENDED that the client display a message to the user at 327 this point, announcing that it has moved into unprotected mode. 328 o The next time the client detects that it has moved, it SHOULD re- 329 initiate an IKE exchange. 331 5. IANA Considerations 333 This document does not create any new namespaces to be maintained by 334 IANA, but it requires new values in namespaces that have been defined 335 in the IKEv2 base specification. 337 This document defines several new IKEv2 notifications whose values 338 are to be allocated from the "IKEv2 Notify Message Types" namespace. 340 Notify Messages - Error Types Value 341 ----------------------------- ----- 342 None 344 Notify Messages - Status Types Value 345 ------------------------------ ----- 346 SECURE_NETWORK_DETECT TBD-BY-IANA1 (16396..40959) 347 SECURE_NETWORK_DETECTED TBD-BY-IANA2 (16396..40959) 349 6. Security Considerations 351 The proposed solution needs to be analyzed carefully, since it may 352 cause a host to switch from protected to unprotected communication. 353 Following are the threats that we have identified. 354 1. The notifications are sent in the clear. A passive attacker will 355 learn whether the responder is receiving traffic over a trusted 356 or untrusted interface. This is information that the attacker is 357 probably able to obtain otherwise. 359 2. An active attacker may be able to change either or both 360 notifications. The first notification N1 does not carry any 361 data, so it can at worst be deleted. In this case the protocol 362 will revert to normal IKE. 363 3. An active attacker's change to the N2 notification (or deletion 364 of N2) will be detected since IKE message #2 is authenticated and 365 integrity-protected. Therefore this attack is only equivalent to 366 a DoS attack on IKE. Moreover, the protocol is "fail safe" since 367 any detected failures or attacks will at worst result in the 368 client using a secure channel where one is not required by 369 policy. 370 4. This protocol can be defeated by an active attacker who can 371 inject packets into the trusted network and relay the responses 372 to such packets back into the untrusted network. Such an 373 attacker will be able to cheat the client into believing that it 374 is on the trusted network. We believe we do not have to address 375 this threat. 376 5. This protocol MUST NOT be used if the network can change the path 377 between the client and the security gateway without the client's 378 awareness, causing its security properties to change. That is, 379 if the network can route traffic sometimes over a trusted path 380 and sometimes over an untrusted one, without notifying the end- 381 point. Such a situation might be possible in incorrectly 382 configured Mobile IP deployments, e.g. where the same Home Agent 383 is shared between a trusted Wi-Fi access network and an untrusted 384 one, and where the IPsec layer is not informed of the 385 connectivity changes. 386 6. There are rare cases when a client is collocated with a NAT. One 387 such case is a client implemented within a software virtual 388 machine. In such cases the client is likely to remain unaware 389 when moving from a trusted to an untrusted network. Therefore we 390 recommend (Section 3.4) to always indicate an untrusted network 391 to clients behind NAT. 393 7. Change Log 395 [[ Note to RFC Editor: please remove this section before publication. 396 ]] 398 7.1. -03 400 Intended status changed to Experimental. 402 7.2. -02 404 Minor editorial changes. 406 7.3. -01 408 Added a section on the client's security policy, per [RFC4301]. 409 Added discussion of the interaction with MOBIKE. Added treatment of 410 client behind NAT. 412 7.4. -00 414 Initial version. 416 8. Acknowledgements 418 We would like to thank Ariel Shaqed for his many useful comments. 419 Thanks to Steve Kent for helping to clarify security policy issues. 421 9. References 423 9.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 429 Internet Protocol", RFC 4301, December 2005. 431 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 432 RFC 4306, December 2005. 434 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 435 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 437 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 438 (MOBIKE)", RFC 4555, June 2006. 440 9.2. Informative References 442 [I-D.ietf-mip4-vpn-problem-solution] 443 Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across 444 IPsec-based VPN Gateways", 445 draft-ietf-mip4-vpn-problem-solution-04 (work in 446 progress), December 2007. 448 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 449 Implementation Guidelines", RFC 4718, October 2006. 451 Authors' Addresses 453 Yaron Sheffer 454 Check Point Software Technologies Ltd. 455 5 Hasolelim st. 456 Tel Aviv 67897 457 Israel 459 Email: yaronf@checkpoint.com 461 Yoav Nir 462 Check Point Software Technologies Ltd. 463 5 Hasolelim st. 464 Tel Aviv 67897 465 Israel 467 Email: ynir@checkpoint.com 469 Full Copyright Statement 471 Copyright (C) The IETF Trust (2008). 473 This document is subject to the rights, licenses and restrictions 474 contained in BCP 78, and except as set forth therein, the authors 475 retain all their rights. 477 This document and the information contained herein are provided on an 478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 480 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 481 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 482 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Intellectual Property 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Acknowledgment 511 Funding for the RFC Editor function is provided by the IETF 512 Administrative Support Activity (IASA).