idnits 2.17.1 draft-ietf-btns-prob-and-applic-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1338. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 301: '... RECOMMENDED."...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 890 has weird spacing: '...ructure e.g....' -- 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 (June 26, 2008) is 5783 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '4') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '5') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '6') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '7') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5201 (ref. '14') (Obsoleted by RFC 7401) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-09 -- Obsolete informational reference (is this intentional?): RFC 3720 (ref. '19') (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 3530 (ref. '21') (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '22') (Obsoleted by RFC 9260) == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-00 == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-07 == Outdated reference: A later version (-07) exists of draft-ietf-btns-core-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BTNS WG J. Touch, D. Black, Y. Wang 2 Internet Draft USC/ISI, EMC, and Microsoft 3 Intended status: Informational June 26, 2008 4 Expires: December 2008 6 Problem and Applicability Statement 7 for Better Than Nothing Security (BTNS) 8 draft-ietf-btns-prob-and-applic-07.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on December 26, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The Internet network security protocol suite, IPsec, requires 43 authentication, usually of network layer entities, to enable access 44 control and provide security services. This authentication can be 45 based on mechanisms such as pre-shared symmetric keys, certificates 46 with associated asymmetric keys, or the use of Kerberos (via KINK). 48 The need to deploy authentication information and its associated 49 identities can be a significant obstacle to the use of IPsec. 51 This document explains the rationale for extending the Internet 52 network security protocol suite to enable use of IPsec security 53 services without authentication. These extensions are intended to 54 protect communication, providing "better than nothing security" 55 (BTNS). The extensions may be used on their own (this use called 56 Stand Alone BTNS, or SAB), or may be used to provide network layer 57 security that can be authenticated by higher layers in the protocol 58 stack (this use is called Channel-Bound BTNS, or CBB). The document 59 also explains situations for which use of SAB and/or CBB extensions 60 are applicable. 62 Table of Contents 64 1. Introduction...................................................3 65 1.1. Authentication............................................3 66 1.2. IPsec Channels and Channel Binding........................4 67 1.3. BTNS Methods..............................................6 68 1.4. BTNS Scope................................................7 69 1.5. Structure of this Document................................7 70 2. Problem Statement..............................................8 71 2.1. Network Layer.............................................8 72 2.1.1. Authentication Identities............................8 73 2.1.2. Authentication Methods...............................9 74 2.1.3. Current IPsec Limits on Unauthenticated Peers........9 75 2.2. Higher Layer Issues.......................................9 76 2.2.1. Transport Protection from Packet Spoofing............9 77 2.2.2. Authentication at Multiple Layers...................11 78 3. BTNS Overview and Threat Models...............................12 79 3.1. BTNS Overview............................................12 80 3.2. BTNS and IPsec Security Services.........................13 81 3.3. BTNS and IPsec Modes.....................................14 82 4. Applicability Statement.......................................16 83 4.1. Benefits.................................................16 84 4.2. Vulnerabilities..........................................17 85 4.3. Stand-Alone BTNS (SAB)...................................17 86 4.3.1. Symmetric SAB.......................................18 87 4.3.2. Asymmetric SAB......................................18 88 4.4. Channel-Bound BTNS (CBB).................................19 89 4.5. Summary of Uses, Vulnerabilities, and Benefits...........19 90 5. Security Considerations.......................................20 91 5.1. Threat Models and Evaluation.............................20 92 5.2. Interaction with Other Security Services.................21 93 5.3. MITM and Masquerader Attacks.............................21 94 5.4. Denial of Service (DoS) Attacks and Resource Consumptions22 95 5.5. Exposure to Anonymous Access.............................22 96 5.6. ICMP Attacks.............................................23 97 5.7. Leap of Faith............................................23 98 5.8. Connection Hijacking through Rekeying....................24 99 5.9. Configuration Errors.....................................25 100 6. Related Efforts...............................................25 101 7. IANA Considerations...........................................25 102 8. Acknowledgments...............................................26 103 9. References....................................................26 104 9.1. Normative References.....................................26 105 9.2. Informative References...................................26 106 Author's Addresses...............................................28 107 Intellectual Property Statement..................................29 108 Disclaimer of Validity...........................................29 110 1. Introduction 112 Network security is provided by a variety of protocols at different 113 layers in the stack. At the network layer, the IPsec protocol suite 114 (consisting of IKE, ESP, and AH) is used to secure IP traffic. IPsec, 115 including the Internet Key Exchange protocol (IKE), offers high 116 levels of security that provide protection from a wide array of 117 possible threats, but authentication is required [5][7][8]. In turn 118 authentication requires deployment of authentication identities and 119 credentials, which can be an obstacle to IPsec usage. This document 120 discusses this dependency, and introduces "Better Than Nothing 121 Security" (BTNS) as one solution, whose goal is to provide a 122 generally useful means of applying IPsec security services without 123 requiring network-layer authentication. 125 1.1. Authentication 127 There are two primary architectural approaches to authentication: 128 employing out-of-band communications and using pre-deployed 129 information. Out-of-band authentication can be done through a trusted 130 third party, via a separate communication channel to the peer, or via 131 the same channel as the communications to be secured, but at a higher 132 layer. Out-of-band authentication requires mechanisms and interfaces 133 to bind the authenticated identities to the secure communication 134 channels, and is out-of-scope for this document (although it may be 135 possible to extend the channel binding mode of BTNS to work with such 136 mechanisms). Pre-deployed information includes identities, pre-shared 137 secrets and credentials that have been authenticated by trusted 138 authorities (e.g., a certificate and its corresponding private key). 140 This form of authentication often requires manual deployment and 141 coordination among communicating peers. Furthermore, obtaining and 142 deploying credentials such as certificates signed by certification 143 authorities (CA) involves additional, protocol and administrative 144 actions that may incur significant time and effort to perform. 146 These factors increase the work required to use IKE with IPsec for 147 peer authentication. Consequently, some users and applications do not 148 use IPsec to protect traffic at the network layer, but rely instead 149 on higher layer security protocols (e.g., TLS [4]) or operate without 150 any security. As the problem statement section will describe, higher 151 layer security protocols may not be enough to protect against some 152 network layer attacks. 154 To improve the situation, one could either reduce the hurdles to 155 obtain and configure authentication information, or remove the 156 requirement for authentication in IPsec. The latter approach is the 157 core idea of BTNS, which provides anonymous (unauthenticated) keying 158 for IPsec to create Security Associations (SAs) with peers that do 159 not possess requisite authentication credentials. This requires 160 extensions to the IPsec architecture. As the new BTNS modes for IPsec 161 relax the authentication requirement, the impacts, tradeoffs, and 162 risks must be thoroughly understood before applying BTNS to any 163 communications. More specifically, this document addresses the issues 164 of whether and when network layer authentication can be omitted, the 165 risks of using BTNS, and finally, the impacts to the existing IPsec 166 architecture. 168 BTNS employs a weaker notion of authenticated identity by comparison 169 to most authentication protocols; this weaker notion is bootstrapped 170 from the security association itself. This notion, called "continuity 171 of association," doesn't mean "Bill Smith" or "owner of shared secret 172 X2YQ", but means "the entity with which I have been communicating on 173 connection #23". Continuity of association is only invariant within a 174 single SA; it is not invariant across SAs, and hence can only be used 175 to provide protection during the lifetime of an SA. This a core 176 notion used by BTNS, particularly in the absence of higher layer 177 authentication. Continuity of association can be viewed as a form of 178 authentication in which an identity is not authenticated across 179 separate associations or out-of-band, but does not change during the 180 lifetime of the SA. 182 1.2. IPsec Channels and Channel Binding 184 When IPsec security services are used by higher layer protocols, it 185 is important to bind those services to higher layer protocol sessions 186 in order to ensure that the security services are consistently 187 applied to the higher layer traffic involved. The result of this 188 binding is an "IPsec channel", and the act of creating an IPsec 189 channel is an instance of channel binding. Channel binding is 190 discussed in RFC-5056 [27] and an associated connection latching 191 document [26]. This subsection summarizes the portions of these 192 documents that are essential to understanding certain aspects of 193 BTNS. 195 A secure channel is a packet, datagram, octet stream connection, or 196 sequence of connections between two endpoints that affords 197 cryptographic integrity and, optionally, confidentiality to data 198 exchanged over it [27]. Applying this concept to IPsec, an "IPsec 199 channel" is a packet flow associated with a higher layer protocol 200 session, such as a TCP connection, where all the packets are 201 protected by IPsec SAs such that: 203 o the peer's identity is the same for the lifetime of the packet 204 flow, and 206 o the quality of IPsec protection used for the packet flow's 207 individual packets is the same for all of them for the lifetime of 208 the packet flow [26]. 210 The endpoints of an IPsec channel are the higher layer protocol 211 endpoints, which are beyond the endpoints of the IPsec SAs involved. 212 This creates a need to bind each IPsec SA to the higher layer 213 protocol session and its endpoints. Failure to do this binding 214 creates vulnerabilities to man-in-the-middle (MITM) attacks where 215 what appears to be a single IPsec SA for the higher layer protocol 216 traffic is actually two separate SAs concatenated by the attacker 217 acting as a traffic forwarding proxy. 219 The combination of connection latching [26] with channel binding 220 [27], creates IPsec channels and binds IPsec SAs to higher layer 221 protocols. Connection latching creates an IPsec channel by 222 associating IPsec SAs to higher layer protocol sessions, and channel 223 binding enables a higher layer protocol to bind its authentication to 224 the IPsec SAs. Caching of this "latch" across higher layer protocol 225 sessions is necessary to counter inter-session spoofing attacks, and 226 the channel binding authentication should be performed on each higher 227 layer protocol session. Connection latching and channel binding are 228 useful not only for BTNS but also for IPsec SAs whose peers are fully 229 authenticated by IKE during creation of the SA. 231 Channel binding for IPsec is based on information obtained from the 232 SA creation process that uniquely identifies an SA pair. Channel 233 binding can be accomplished by adding this identifying information to 234 higher layer authentication mechanisms based on one-way hashes, key 235 exchanges, or (public key) cryptographic signatures; in all three 236 cases, the resulting higher-layer authentication resists man-in-the- 237 middle attacks on SA creation. When each IKE peer uses a public- 238 private key pair for IKE authentication to create an SA pair, the 239 pair of public keys used (one for each peer) suffices for channel 240 binding; strong incorporation of this information into higher layer 241 authentication causes that higher layer authentication to fail when 242 an MITM attacker has concatenated separate SAs by acting as a traffic 243 forwarding proxy. 245 1.3. BTNS Methods 247 There are two classes of scenarios in which BTNS may be used to apply 248 IPsec services without network-layer authentication: 250 1. Protection of traffic for a higher-layer protocol that does not 251 use authentication. The resulting protection is "better than 252 nothing" because once an unauthenticated SA is successfully 253 created without an MITM, that SA's IPsec security services resist 254 subsequent MITM attacks even though the absence of authentication 255 allows the initial creation of the BTNS-based security 256 association (SA) to be subverted by an MITM. This method of using 257 BTNS is called Stand-Alone BTNS (SAB) because it does not rely on 258 any security services outside of IPsec. 260 2. Protection of traffic generated by a higher-layer protocol that 261 uses authentication. The "better than nothing" protection in this 262 case relies on the strength of the higher-layer protocol's 263 authentication and the channel binding of that authentication 264 with the BTNS-based SAs. The level of protection may be 265 comparable to the level afforded by the use of network-layer IKE 266 authentication when the higher-layer protocol uses strong 267 authentication and strong channel binding is employed to 268 associate the BTNS-based SA with that higher-layer 269 authentication. This method of using BTNS is called Channel-Bound 270 BTNS (CBB) when the combination of the higher-layer 271 authentication and channel binding is sufficient to detect an 272 MITM attack on creation of a BTNS-based SA. 274 It is possible to combine IKE authentication for one end of an SA 275 pair with BTNS's absence of network layer authentication for the 276 other end. The resulting asymmetric authentication creates asymmetric 277 modes of BTNS that are discussed further in Section 3.2 below. 279 1.4. BTNS Scope 281 The scope of BTNS is to provide a generally useful means of applying 282 IPsec security services that does not require network-level 283 authentication credentials. The following areas are outside this 284 scope of BTNS and hence are not discussed further in this document: 286 1. Use of security frameworks other than IPsec to provide security 287 services for higher layer protocols. There are an variety of 288 security service frameworks other than IPsec, such as TLS[4], 289 SASL [11] and GSSAPI [10], as well as a variety of non-IPsec 290 security mechanisms such as TCP MD5 [6] that are described in 291 other documents. BTNS is based on IPsec by design; it will not 292 always be the most appropriate solution. 294 2. Use of the Extensible Authentication Protocol (EAP) for IKE 295 authentication. Section 1.3 of RFC-3748 clearly restricts EAP's 296 applicability to network access protocols [1]: 298 "EAP was designed for use in network access authentication, 299 where IP layer connectivity may not be available. Use of EAP 300 for other purposes, such as bulk data transport, is NOT 301 RECOMMENDED." 303 Hence EAP authentication for IKE is only applicable to situations 304 where IKE is being used to establish network access (e.g., create 305 a VPN connection). In contrast, the BTNS goal of general 306 applicability encompasses many areas other than network access 307 and specifically includes protocols that transfer large amounts 308 of data, such as iSCSI [19] and NFSv4 [21]. 310 3. Manual keying is not considered for BTNS because manual keying is 311 unsafe for protocols that transfer large amounts of data (e.g., 312 RFC-3723 forbids use of manual keying with the IP Storage 313 protocols, including iSCSI, for this reason [2]). 315 1.5. Structure of this Document 317 The next section discusses the motivations for BTNS primarily based 318 on the implications of IKE's requirements for network layer 319 authentication. Section 3 provides a high level overview of BTNS, 320 both SAB and CBB. Section 3 also includes descriptions of the 321 security services offered and the BTNS modes of operation (based on 322 combinations of SAB, CBB, and/or IKE authentication). Section 4 323 explores the applicability of all of the modes of BTNS. This is 324 followed by a discussion of the risks and other security 325 considerations in Section 5. Section 6 briefly describes other 326 related efforts. 328 2. Problem Statement 330 This section describes the problems that motivated the development of 331 BTNS. The primary concern is that IPsec is not widely utilized 332 despite rigorous development effort and emphasis on network security 333 by users and organizations. There are also differing viewpoints on 334 which layer is best for securing network communications, and how 335 security protocols at different layers should interact. The following 336 discussion roughly categorizes these issues by layers: network layer 337 and higher layers. 339 2.1. Network Layer 341 At the network layer, one of the hurdles is to satisfy the 342 authentication requirements of IPsec and IKE. This section discusses 343 some drawbacks of network layer authentication and the results of 344 these requirements. 346 2.1.1. Authentication Identities 348 Current IPsec authentication supports several types of identities in 349 the Peer Authorization Database (PAD): IPv4 addresses, IPv6 350 addresses, DNS names, Distinguished Names, RFC 822 email addresses, 351 and Key IDs [8]. All require either certificates or pre-shared 352 secrets to authenticate. The identities supported by the PAD can be 353 roughly categorized as network layer identifiers or other 354 identifiers. 356 The first three types of identifiers, IPv4 addresses, IPv6 addresses 357 and DNS names are network layer identifiers. The main deficiency of 358 IP addresses as identifiers is that they often do not consistently 359 represent the same physical systems due to the increasing use of 360 dynamic address assignments (DHCP) and system mobility. The use of 361 DNS names is also affected because the name to address mapping is not 362 always up to date as a result. Stale mapping information can cause 363 inconsistencies between the IP address recorded in the DNS for a 364 named system and the actual IP address of that system, leading to 365 problems if the DNS is used to cross-check the IP address from which 366 a DNS name was presented as an identifier. DNS names are also not 367 always under the control of the endpoint owner. 369 There are two main drawbacks with the other, non-network-layer 370 identifiers defined for the PAD. The PAD functionality can be overly 371 restrictive because there are other forms of identifiers not covered 372 by the PAD specification (EAP does not loosen these restrictions in 373 general; see Section 1.4). Use of any non-network layer identifiers 374 for IPsec authentication may result in multiple authentications for 375 the same or different identifiers at different layers, creating a 376 need to associate authentications and new error cases (e.g., one of 377 two authentications for the same identifier fails). These issues are 378 also related to channel binding and are further discussed later in 379 this document. 381 2.1.2. Authentication Methods 383 As described earlier, certificates and pre-shared secrets are the 384 only methods of authentications accepted by current IPsec and IKE 385 specifications. Pre-shared secrets require manual configuration and 386 out-of-band communications. The verification process for certificates 387 is cumbersome, plus there are administrative and potential monetary 388 costs in obtaining certificates. These factors are among the possible 389 reasons why IPsec is not widely used outside of environments with the 390 highest security requirements. 392 2.1.3. Current IPsec Limits on Unauthenticated Peers 394 Pre-configuration of SPD "bypass" entries to enable communication 395 with unauthenticated peers only works if the peer IP addresses are 396 known in advance. The lack of unauthenticated IPsec modes often 397 prevents secure communications at the network layer with 398 unauthenticated or unknown peers, even when they are subsequently 399 authenticated in a higher layer protocol or application. The lack of 400 a channel binding API between IPsec and higher layer protocols may 401 further force such communications to completely bypass IPsec, leaving 402 the network layer of such communications unprotected. 404 2.2. Higher Layer Issues 406 For higher layers, the next subsection focuses on whether IPsec is 407 necessary if transport layer security is already in use. The use of 408 IPsec in the presence of transport security provides further motivate 409 for reducing the administrative burdens of using IPsec. This is 410 followed by a discussion of the implications of using authentication 411 at both the network layer and a higher layer for the same connection. 413 2.2.1. Transport Protection from Packet Spoofing 415 Consider the case of transport protocols. Increases in network 416 performance and the use of long-lived connections have resulted in 417 increased vulnerability of connection-oriented transport protocols to 418 certain forms of attacks. TCP, like many other protocols, is 419 susceptible to off-path third-party attacks, such as injection of a 420 TCP RST [24]. The Internet lacks comprehensive ingress filtering to 421 discard such spoofed traffic before it can cause damage. These 422 attacks can affect BGP sessions between core Internet routers, and 423 are thus of significant concern [3][12]. As a result, a number of 424 proposed solutions have been developed, most of which are at the 425 transport layer. 427 Some of these solutions augment the transport protocol by improving 428 its own security, e.g., TCP MD5 [6]. Others modify the core TCP 429 processing rules to make it harder for off-path attackers to inject 430 meaningful packets either during the initial handshake (e.g. SYN 431 cookies) or after a connection is established (e.g., TCPsecure) 432 [15][23]. Some of these approaches are new to TCP, but have already 433 been incorporated into other transport protocols (e.g., SCTP [22]) or 434 intermediate (so-called layer 3.5) protocols (e.g., HIP [14]). 436 TCP MD5 and its potential successor, TCP Auth [25] are based on 437 authentication; TCP-specific modifications that lack authentication 438 are, at best, temporary patches to the ubiquitous vulnerability to 439 spoofing attacks. The obvious solution to spoofing is end-to-end 440 validation of the traffic, either at the transport layer or the 441 network layer. The IPsec suite already provides authentication of a 442 network layer packet and its contents, but the costs of an 443 authentication infrastructure required for the use of IPsec can be 444 prohibitive. Similarly, TCP MD5 requires pre-shared keys, which can 445 likewise be prohibitive. TCP Auth is currently under development, and 446 may include a BTNS-like mode. 448 Protecting systems from spoofed packets is ultimately an issue of 449 authentication, ensuring that a receiver's interpretation of the 450 source of a packet is accurate. Authentication validates the identity 451 of the source of the packet. The current IPsec suite assumes that 452 identity is validated either by a trusted third party - e.g., a 453 certification authority - or by a pre-deployed shared secret. Such an 454 identity is unique and invariant across associations (pair-wise 455 security configuration), and can be used to reject packets that are 456 not authentic. 458 With regard to BGP in particular, it has been understood that the use 459 of appropriate network or transport layer authentication is the 460 preferred protection from TCP spoofing attacks [3]. Authentication, 461 at one router by itself does not provide overall BGP security because 462 that router remains at the mercy of all routers it peers with, since 463 it depends on them to also support authentication [25]. The reality 464 is that few Internet routers are configured to support authentication 465 at all, and the result is the use of unsecured TCP for sending BGP 466 packets. BTNS allows an individual router to relax the need for 467 authentication, in order to enable the use of protected sessions that 468 are not authenticated. The latter is "better than nothing" in cases 469 where "nothing" is the alternative. Although the routing community 470 has chosen solutions other than BTNS for protection of BGP's TCP 471 connections (e.g., TCP MD5), the discussion of BGP remains in this 472 document because it was a motivation for the development of BTNS. 474 2.2.2. Authentication at Multiple Layers 476 Some existing protocols used on the Internet provide authentication 477 above the network and transport layers, but rely on the IPsec suite 478 for packet-by-packet cryptographic integrity and confidentiality 479 services. Examples of such protocols include iSCSI [19] and the 480 remote direct data placement (RDDP) protocols [16][20]. With the 481 current IPsec suite, the result is two authentication operations; one 482 at the IPsec layer using an identity for IKE and an associated secret 483 or key, and another by the higher layer protocol using a higher layer 484 identity and secret or key. With the current IPsec specifications, 485 this redundant authentication is necessary, because the identity and 486 key formats differ between IPsec and the higher layer protocol, 487 and/or because there is no standard interface to pass authentication 488 results from IPsec up to the higher layer. End-node software is then 489 responsible for ensuring that the identities used for these two 490 authentication operations are consistent in some fashion, an 491 authorization policy decision. 493 Failure of the end-node software to enforce appropriate consistency 494 across authentication operations at different layers creates man-in- 495 the-middle attack opportunities at the network layer. An attacker may 496 exploit this omission by interposing as a proxy; rather than 497 impersonate the attacked endpoints, the attacker need only 498 authenticate with identities that are acceptable to the attacked 499 endpoints. The resulting success enables the attacker to obtain full 500 access to the higher layer traffic, by passing the higher layer 501 authentication operation through without modification. In the 502 complete absence of consistency checks on the identities used at 503 different layers, higher layer traffic may be accessible to any 504 entity that can successfully authenticate at the network layer. 506 In principle a single authentication operation should suffice to 507 protect the higher layer traffic, removing the need for: 509 o the second authentication operation 510 o configuration and management of the identities and secrets or keys 511 for the second authentication (even if the identities and secrets 512 or keys are the same, the two authentication operations may employ 513 different repositories for identities, secrets, and keys). 515 o determining in some fashion that the two authenticated identities 516 are consistent. As noted above, there are significant potential 517 MITM vulnerabilities if this is not done. 519 IPsec may not always be present for these higher layer protocols, and 520 even when present, may not always be used. Hence, if there is a 521 choice, the higher layer protocol authentication is preferable as it 522 will always be available for use independent of IPsec. 524 A "better than nothing" security approach to IPsec can address this 525 problem by setting up an IPsec security association without an 526 authentication, and then using an extended form of the higher layer 527 authentication to establish that the higher layer protocol session is 528 protected by a single IPsec SA. This counters man-in-the-middle 529 (MITM) attacks on BTNS IPsec session establishment by terminating the 530 higher layer session via an authentication failure when such an 531 attack occurs. The result is that a single authentication operation 532 validates not only the higher layer peer's identity, but also 533 continuity of the security association to that peer. This higher 534 layer check for a single IPsec SA is referred in this document as 535 "channel binding", thus the name Channel-Bound BTNS (CBB) [27]. 537 3. BTNS Overview and Threat Models 539 This section provides an overview of BTNS and the IPsec security 540 services that are offered when BTNS is used. It also describes the 541 multiple operating modes of BTNS. 543 3.1. BTNS Overview 545 This is an overview of what is needed in IPsec to enable BTNS. The 546 detailed specifications of the extensions are addressed by the 547 relevant protocol specifications. 549 The main update to IPsec is adding extensions to security policy that 550 permit secure communications with un-authenticated peers. These 551 extensions are necessary for both IPsec and IKE. For IPsec, the first 552 extension applies to the PAD, which specifies the forms of 553 authentication allowed for each IKE peer. In addition to existing 554 forms of authentication such as X.509 certificates and pre-shared 555 secrets, the extension adds an un-authenticated category in which the 556 public key presented by the peer serves as its identity (and is 557 authenticated by the peer demonstrating knowledge of the 558 corresponding private key) [28]. The second extension is that a flag 559 is added to each SPD entry is extended to indicate whether BTNS lack 560 of authentication is acceptable for that SPD entry. 562 The changes to enable channel binding between IPsec and higher layer 563 protocols or applications are more complex than the policy extensions 564 above. They require specifying APIs and interactions between IPsec 565 and higher layer protocols. This document assumes such provisions 566 will be developed, but does not address their details. 568 3.2. BTNS and IPsec Security Services 570 The changes and extensions of BTNS primarily affect IPsec policy as 571 described above. Other parts of IPsec and IKE specifications are 572 unchanged. BTNS does not require a separate IPsec implementation, as 573 BTNS can be integrated with any IPsec implementation in a system. The 574 scope of BTNS functionality applies only to the SAs matching the 575 policies that explicitly specify or enable BTNS modes in the PAD and 576 for which the corresponding SPD entries allow BTNS. All other non- 577 BTNS policy entries, including entries in the SPD and the PAD, and 578 any non-BTNS SAs are not affected by BTNS. 580 In principle, the result of removing the requirement that all SAs be 581 authenticated is that BTNS can establish secure IPsec connections in 582 a fashion similar to fully authenticated IKE, but BTNS cannot verify 583 or authenticate the peer identities of these SAs. The following is a 584 list of security services offered by the IPsec protocol suite with 585 notes that address the differences created by the addition of BTNS. 587 1. Access Control 589 BTNS extends IPsec's access control services to allow 590 unauthenticated connections. These extensions are integrated with 591 the IPsec PAD and SPD in a fashion that does not affect the 592 access controls associated with entries that do not use the BTNS 593 extensions. For Channel-Bound BTNS, the authentication that 594 applies to the SA is performed at a higher layer in a fashion 595 that links higher layer access control policy to IPsec's network 596 layer access control mechanisms. 598 2. Data Origin Authentication 600 Stand-Alone BTNS weakens data origin authentication to continuity 601 of association, namely the assurance that traffic on an SA 602 continues to originate from the same unauthenticated source. 604 Channel-Bound BTNS relies on higher layer authentication to 605 provide data origin authentication of protected network traffic. 607 3. Connectionless Integrity 609 4. Anti-Replay Protection 611 5. Confidentiality 613 6. (Limited) Traffic Flow Confidentiality 615 For the remaining security services offered by IPsec, items 3 616 through 6, it is possible to establish secure IPsec connections 617 with rogue peers via BTNS because authentication is not required. 618 On the other hand, once a secure connection is established, the 619 communication is protected by these security services in the same 620 fashion as a connection established by conventional IPsec means. 622 3.3. BTNS and IPsec Modes 624 The previous sections have described two ways of using BTNS: Stand- 625 alone (SAB) and Channel-Bound (CBB). Both of these can also be used 626 either symmetrically, where neither party authenticates at the 627 network layer, or asymmetrically, where only one party does not 628 authenticate at the network layer. There are a number of cases to 629 consider, based on combinations of the endpoint security capabilities 630 of SAB, CBB, and conventional IKE authentication of an identity 631 (denoted as AUTH below). The following tables show all of the 632 combinations based on the capabilities of the two security endpoints: 634 | AUTH | SAB | | CB-AUTH | CBB | 635 -----+-------+-------+ -------+---------+---------+ 636 | | | | | | 637 AUTH | AUTH | A-SAB | CB-AUTH| CB-AUTH | A-CBB | 638 | | | | | | 639 -----+-------+-------+ -------+---------+---------+ 640 | | | | | | 641 SAB | A-SAB | S-SAB | CBB | A-CBB | S-CBB | 642 | | | | | | 643 -----+-------+-------+ -------+---------+---------+ 645 No Channel Binding With Channel Binding 647 There are six operating modes that result from the combinations. The 648 first three modes consist of network layer authentication schemes 649 used without channel binding to higher layer authentication: 651 1. AUTH: both parties provide and authenticate conventional, IKE- 652 supported identities. 654 2. Symmetric SAB (S-SAB): neither party authenticates with a 655 conventional, IKE-supported identity. 657 3. Asymmetric SAB (A-SAB): one party does not authenticate with a 658 conventional IKE-supported identity, but the other side does 659 authenticate with such an identity. 661 The following three modes combine the network layer behaviors with 662 channel binding to higher layer authentication credentials: 664 4. CB-AUTH: channel binding is used and both parties authenticate 665 with conventional IKE-supported identities. 667 5. Symmetric CBB (S-CBB): neither party authenticates with a 668 conventional, IKE-supported identity, but channel binding is used 669 to bind the SAs to higher layer authentication operations. 671 6. Asymmetric CBB (A-CBB): this is asymmetric SAB (A-SAB) used with 672 channel binding; at the network layer, one party does not 673 authenticate with a conventional IKE-supported identity, but the 674 other party does authenticate with such an identity, and channel 675 binding is used to bind the SA to higher layer authentication 676 operations. 678 There are three security mechanisms involved in BTNS with channel 679 binding: 681 1. BTNS and IPsec at the network layer 683 2. higher layer authentication, and 685 3. the connection latching plus channel binding mechanisms that bind 686 the higher layer authentication credentials with the secure IPsec 687 channel. 689 Authentication at both the network and higher layers can be either 690 bidirectional (both peers are authenticated) or unidirectional (one 691 of the two peers does not authenticate). In contrast, when channel 692 binding is used, it must be applied at both ends of the communication 693 to prevent MITM attacks. Existing channel binding mechanisms and APIs 694 for this purpose (e.g., as defined in GSS-API [10]) mandate the 695 exchange and verification of the channel binding values at both ends 696 to ensure that correct, non-spoofed channel characteristics are bound 697 to the higher layer authentication. 699 Note: When any of Stand-Alone BTNS, SAB, Channel-Bound BTNS or CBB is 700 used without being qualified as symmetric or asymmetric, the 701 symmetric mode is the intended default meaning. 703 4. Applicability Statement 705 BTNS is intended for services open to the public but for which 706 protected associations are desired, and for services that can be 707 authenticated at higher layers in the protocol stack. BTNS can also 708 provide some level of protection for private services when the 709 alternative to use of BTNS is no protection at all. 711 BTNS uses the IPsec protocol suite, and therefore should not be used 712 in situations where IPsec and specifically IKE are unsuitable. IPsec 713 and IKE incur additional computation overhead, and IKE further 714 requires message exchanges that incur round-trip latency to setup 715 security associations. These may be undesirable in environments with 716 limited computational resources and/or high communication latencies. 718 This section provides an overview of the types of applications 719 suitable for various modes of BTNS. The next two sections describe 720 the overall benefits and vulnerabilities, followed by the 721 applicability analysis for each BTNS mode. The applicability 722 statement covers only the four BTNS-specific modes; the AUTH and 723 CB-AUTH modes are out of scope for this discussion. 725 4.1. Benefits 727 BTNS protects security associations after they are established by 728 reducing vulnerability to attacks from parties that are not 729 participants in the association. BTNS-based SAs protect network and 730 transport layers without requiring network layer authentication. BTNS 731 can be deployed without pre-deployment of authentication material for 732 IPsec or pre-shared information, and can protect all transport layer 733 protocols using a common mechanism. 735 BTNS also helps protect systems from low-effort attacks on higher 736 layer sessions or connections that disrupt valuable services or 737 resources. BTNS raises the level of effort for many types of network 738 and transport layer attacks. Simple transport layer packet attacks 739 are rejected because the malicious packet or packets are not part of 740 an IPsec SA. The attacker is instead forced to establish an 741 unauthenticated IPsec SA and a transport connection for SAB, 742 requiring the attacker to perform as much work as a host engaging in 743 the higher layer communication. SAB thus raises the effort for a DDoS 744 (Distributed Denial of Service) attack to that of emulating a flash 745 crowd. For open services, there may be no way to distinguish such a 746 DDoS attack from an actual flash crowd. 748 BTNS also allows individual security associations to be established 749 for protection of higher layer traffic without requiring pre-deployed 750 authentication credentials. 752 4.2. Vulnerabilities 754 BTNS removes the requirement that every IPsec SA be authenticated. 755 Hosts connecting to BTNS hosts are vulnerable to communicating with a 756 masquerader throughout the association for SAB, or until higher 757 layers provide additional authentication for CBB. As a result, 758 authentication data (e.g., passwords) sent to a masquerading peer 759 could be disclosed to an attacker. This is a deliberate design 760 tradeoff; in BTNS, network and transport layer access is no longer 761 controlled by the identity presented by the other host, opening hosts 762 to potential masquerading and flash crowd attacks. Conversely, BTNS 763 can secure connections to hosts that are unable to authenticate at 764 the network layer, so the network and transport layers are more 765 protected than can be achieved via higher layer authentication alone. 767 Lacking network layer authentication information, other means must be 768 used to provide access control for local resources. Traffic selectors 769 for the BTNS SPD entries can be used to limit which interfaces, 770 address ranges, and port ranges can access BTNS-enabled services. 771 Rate limiting can further restrict resource usage. For SAB, these 772 protections need to be considered throughout associations, whereas 773 for CBB they need be present only until higher layer protocols 774 provide the missing authentication. CBB also relies on the 775 effectiveness of the binding of higher layer authentication to the 776 BTNS network association. 778 4.3. Stand-Alone BTNS (SAB) 780 SAB is intended for applications that are unable to use IKE- 781 compatible authentication credentials and do not employ higher layer 782 authentication or other security protection. SAB is also suitable 783 when the identities of either party are not important, or are 784 deliberately omitted, but IPsec security services are desired (see 785 Section 3.2). SAB is particularly applicable to long-lived 786 connections or sessions for which assurance that the entity at the 787 other end of the connection has not changed may be a good enough 788 substitute for the lack of authentication. This section discusses 789 symmetric and asymmetric SAB. 791 4.3.1. Symmetric SAB 793 Symmetric SAB (S-SAB) is applicable when both parties lack network 794 layer authentication information and that authentication is not 795 available from higher layer protocols. S-SAB can still provide some 796 forms of protection for network and transport protocols, but does not 797 provide authentication beyond continuity of association. S-SAB is 798 useful in situations where transfer of large files or use of other 799 long-lived connections would benefit from not being interrupted by 800 attacks on the transport connection (e.g., via a false TCP RST), but 801 the particular endpoint identities are not important. 803 Open services, such as web servers, and peer-to-peer networks could 804 utilize S-SAB when their identities need not be authenticated, but 805 their communication would benefit from protection. Such services 806 might provide files either not validated or validated by other means 807 (e.g., published hashes). These transmissions present a target for 808 off-path attacks that could be mitigated by S-SAB. S-SAB may also be 809 useful for protecting voice-over-IP (VoIP) traffic between peers, 810 such as direct calls between VoIP clients. 812 S-SAB is also useful in protecting any transport protocol when the 813 endpoints do not deploy authentication, for whatever reason. This is 814 the case for BGP TCP connections between core routers, where the 815 protection afforded by S-SAB is better than no protection at all, 816 even though BGP is not intended as an open service. 818 S-SAB can also serve as an intermediate step towards S-CBB. S-SAB is 819 the effective result when an IPsec channel is used (via connection 820 latching), but the higher layer authentication is not bound to the 821 IPsec SAs within the channel. 823 4.3.2. Asymmetric SAB 825 Asymmetric SAB (A-SAB) allows one party lacking network layer 826 authentication information to establish associations with another 827 party that possesses authentication credentials for any applicable 828 IKE authentication mechanism. 830 Asymmetric SAB is useful for protecting transport connections for 831 open services on the Internet, e.g., commercial web servers, etc. In 832 these cases, the server is typically authenticated by a widely known 833 CA, as is done with TLS at the application layer, but the clients 834 need not be authenticated [4]. Although this may result in IPsec and 835 TLS being used on the same connection, this duplication of security 836 services at different layers is necessary when protection is required 837 from the sorts of spoofing attacks described in the problem statement 838 section (e.g., TLS cannot prevent a spoofed TCP RST, as the RST is 839 processed by TCP rather than being passed to TLS). 841 A-SAB can also secure transport for streaming media such as would be 842 used by webcasts for remote education and entertainment. 844 4.4. Channel-Bound BTNS (CBB) 846 CBB allows hosts without network layer authentication information to 847 cryptographically bind BTNS-based IPsec SAs to authentication at 848 higher layers. CBB is intended for applications that employ higher 849 layer authentication, but that also benefit from additional network 850 layer security. CBB provides network layer security services without 851 requiring authentication at the network layer. This enables IPsec 852 security services for applications that have IKE-incompatible 853 authentication credentials. CBB allows IPsec to be used with 854 authentication mechanisms not supported by IKE, and frees higher 855 layer applications and protocols from duplicating security services 856 already available in IPsec. 858 Symmetric CBB integrates channel binding with S-SAB, as does 859 asymmetric CBB with A-SAB. In both cases, the target applications 860 have similar characteristics at the network layer to their non- 861 channel-binding counterparts. The only significant difference is the 862 binding of authentication credentials at higher layer to the 863 resulting IPsec channels. 865 Although the modes of CBB refer to the authentication at the network 866 layer, higher layer authentication can also be either asymmetric 867 (one-way) or symmetric (two-way). Asymmetric CBB can be used to 868 complement one-way authentication at higher layer by providing one- 869 way authentication of the opposite direction at the network layer. 870 Consider an application with one-way, client-only authentication. The 871 client can utilize A-CBB where the server must present IKE- 872 authenticated credentials at the network layer. This form of A-CBB 873 achieves mutual authentication albeit at separate layers. Many remote 874 file system protocols, such as iSCSI and NFS, fit into this category, 875 and can benefit from channel binding with IPsec for better network 876 layer protection including prevention of MITM attacks. 878 Mechanisms and interfaces for BTNS channel binding with IPsec are 879 discussed in further detail in [26]. 881 4.5. Summary of Uses, Vulnerabilities, and Benefits 883 The following is a summary of the properties of each type of BTNS 884 based on the previous subsections: 886 SAB CBB 887 -------------------------------------------------------------- 888 Uses Open services Same as SAB but with 889 Peer-to-peer higher layer auth., 890 Zero-config Infrastructure e.g., iSCSI [19], NFSv4 [21] 892 Vuln. Masqueraders Masqueraders until bound 893 Needs data rate limit Needs data rate limit 894 Load on IPsec Load on IPsec 895 Exposure to open access 897 Benefit Protects L3 & L4 Protects L3 & L4 898 Avoids all auth. keys Avoids L3 auth keys 899 Full auth. once bound 901 Most of the potential vulnerabilities in the above table have been 902 discussed in previous sections of this document; some of the more 903 general issues, such as the increased load on IPsec processing, are 904 addressed in the Security Considerations section of this document. 906 5. Security Considerations 908 This section describes the threat models for BTNS, and discusses 909 other security issues based on the threat models for different modes 910 of BTNS. Some of the issues were mentioned previously in the 911 document, but are listed again for completeness. 913 5.1. Threat Models and Evaluation 915 BTNS is intended to protect sessions from a variety of threats, 916 including on-path, man-in-the-middle attacks after key exchange and 917 off-path attacks. It is intended to protect the contents of a session 918 once established, but does not protect session establishment itself. 919 This protection has value because it forces the attacker to target 920 connection establishment as opposed to waiting for a more convenient 921 time; this is of particular value for long-lived sessions. 923 BTNS is not intended to protect the key exchange itself, so this 924 presents an opportunity for a man-in-the-middle attack or a well- 925 timed attack from other sources. Furthermore, Stand-Alone BTNS is not 926 intended to protect the endpoint from nodes masquerading as 927 legitimate clients of a higher layer protocol or service. Channel- 928 Bound BTNS can protect from such masquerading, though at a later 929 point after the security association is established, as a masquerade 930 attack causes a client authentication failure at a higher layer. 932 BTNS is also not intended to protect from DoS (Denial of Service) 933 attacks that seek to overload a CPU performing authentication or 934 other security computations, nor is BTNS intended to provide 935 protection from configuration mistakes. These latter two threat 936 assumptions are also the case for IPsec. 938 The following sections discuss the implications of the threat models 939 in more details. 941 5.2. Interaction with Other Security Services 943 As with any aspect of network security, the use of BTNS must not 944 interfere with other security services. Within IPsec, the scope of 945 BTNS is limited to the SPD and PAD entries that explicitly specify 946 BTNS, and to the resulting SAD entries. It is incumbent on system 947 administrators to deploy BTNS only where safe, preferably as an 948 alternative to the use of "bypass" SPD entries that exempt specified 949 traffic from IPsec cryptographic protection. In other words, BTNS 950 should be used only as a substitute for no security, rather than as a 951 substitute for stronger security. When the higher layer 952 authentication required for CBB is not available, other methods, such 953 as IP address filtering, can help reduce the vulnerability of SAB to 954 exposure to anonymous access. 956 5.3. MITM and Masquerader Attacks 958 Previous sections have described how CBB can counter MITM and 959 masquerader attacks, even though BTNS does not protect key exchange 960 and does not authenticate peer identities at the network layer. 961 Nonetheless, there are some security issues regarding CBB that must 962 be carefully evaluated before deploying BTNS. 964 For regular IPsec/IKE, a man in the middle cannot subvert IKE 965 authentication, and hence an attempt to attack an IPsec SA via use of 966 two SAs concatenated by the attacker acting as a traffic forwarding 967 proxy will cause an IKE authentication failure. On the other hand, a 968 man-in-the-middle attack on IPsec with CBB is discovered later. With 969 CBB, the IKE protocol will succeed because it is unauthenticated, and 970 the security associations will be set up. The man in the middle will 971 not be discovered until the higher layer authentication fails. There 972 are two security concerns with this approach: possible exposure of 973 sensitive authentication information to the attackers, and resource 974 consumption before attacks are detected. 976 The exposure of information depends on the higher layer 977 authentication protocols used in applications. If the higher layer 978 authentication requires exchange of sensitive information (e.g., 979 passwords or password-derived materials) that are directly useful or 980 can be attacked offline, an attacker can gain such information even 981 though the attack can be detected. Therefore, CBB must not be used 982 with higher layer protocols that may expose sensitive information 983 during authentication exchange. For example, Kerberos V AP exchanges 984 would leak little other than the target's krb5 principal name, while 985 Kerberos V AS exchanges using PA-ENC-TIMESTAMP pre-authentication 986 would leak material that can then be attacked offline. The latter 987 should not be used with BTNS, even with Channel Binding. Further, the 988 ways in which BTNS is integrated with the higher layer protocol must 989 take into consideration vulnerabilities that could be introduced in 990 the APIs between these two systems or in the information that they 991 share. 993 The resource consumption issue is addressed in the next section on 994 DoS attacks. 996 5.4. Denial of Service (DoS) Attacks and Resource Consumptions 998 A consequence of BTNS deployment is that more traffic requires 999 cryptographic operations; these operations increase the computation 1000 required in IPsec implementations that receive protected traffic 1001 and/or verify incoming traffic. That additional computation raises 1002 vulnerability to overloading, which may be the result of legitimate 1003 flash crowds or from a DoS or DDoS attack. Although this may itself 1004 present a substantial impediment to deployment, it is an issue for 1005 all cryptographically protected communication systems. This document 1006 does not address the impact BTNS has on such increases in required 1007 computation. 1009 The effects of the increased resource consumption are twofold. The 1010 consumption raises the level of effort for attacks such as MITM, but 1011 also consumes more resources to detect such attacks and to reject 1012 spoofed traffic. At the network layer, proper limits and access 1013 controls for resources should be setup for all BTNS SAs. CBB SAs may 1014 be granted increased resource access after the higher layer 1015 authentications succeed. The same principles apply to the higher 1016 layer protocols that use CBB SAs. Special care must be taken to avoid 1017 excessive resource usage before authentication is established in 1018 these applications. 1020 5.5. Exposure to Anonymous Access 1022 The use of SAB by a service implies that the service is being offered 1023 for open access, since network layer authentication is not performed. 1024 SAB should not be used with services that are not intended to be 1025 openly available. 1027 5.6. ICMP Attacks 1029 This document does not consider ICMP attacks because the use of BTNS 1030 does not change the existing IPsec guidelines on ICMP traffic 1031 handling [8]. BTNS focuses on authentication part of establishing 1032 security associations. BTNS does not alter the IPsec traffic 1033 processing model and protection boundary. As a result, the entire 1034 IPsec packet processing guidelines, including ICMP processing, remain 1035 applicable when BTNS is added to IPsec. 1037 5.7. Leap of Faith 1039 BTNS allows systems to accept and establish security associations 1040 with peers without authenticating their identities. This can enable 1041 functionality similar to "Leap of Faith" authentication utilized in 1042 other security protocols and applications such as SSH [29]. 1044 SSH implementations are allowed to accept unknown peer credentials 1045 (host public keys) without authentication, and these unauthenticated 1046 credentials may be cached in local databases for future 1047 authentication of the same peers. Similar to BTNS, such measures are 1048 allowed due to the lack of 'widely deployed key infrastructure' [29] 1049 and to improve ease of use and end-user acceptance. 1051 There are subtle differences between SSH and BTNS regarding Leap of 1052 Faith as shown in the following Table: 1054 | SSH | BTNS | 1055 -------------------------------+---------+---------+ 1056 Accept unauthenticated | Allowed | Allowed | 1057 Credentials | | | 1058 -------------------------------+---------+---------+ 1059 Options/Warnings to reject | Yes | No | 1060 unauthenticated credentials | | | 1061 -------------------------------+---------+---------+ 1062 Cache unauthenticated |Required | Allowed | 1063 credential for future refs | | | 1064 -------------------------------+---------+---------+ 1066 SSH requires proper warnings and options in applications to reject 1067 unauthenticated credentials, while BTNS accepts such credentials 1068 automatically when they match the corresponding policy entries. Once 1069 SSH accepts a credential for the first time, that credential should 1070 be cached, and can be reused automatically without further warnings. 1071 BTNS credentials can be cached for future use, but there is no 1072 security advantage to doing so, as a new unauthenticated credential 1073 that is allowed by the policy entries will be automatically accepted. 1075 In addition, BTNS does not require IPsec to reuse credentials in a 1076 manner similar to SSH. When IPsec does reuse unauthenticated 1077 credentials, there may be implementation advantages to caching them. 1079 SSH-style credential caching for reuse with SAB could be addressed by 1080 future extension(s) to BTNS; such extension(s) would need to provide 1081 warnings about unauthenticated credentials and a mechanism for user 1082 acceptance or rejection of them in order to establish a level of 1083 authentication assurance comparable to SSH's "Leap of Faith." Such 1084 extension(s) would also need to deal with issues caused by the 1085 absence of identities in BTNS. At best a cached BTNS credential 1086 reauthenticates the network-layer source of traffic when the 1087 credential is reused - in contrast, SSH credential reuse 1088 reauthenticates an identity. 1090 Network layer re-authentication for SAB is further complicated by: 1092 o the ability of NATs to cause multiple independent network layer 1093 sources of traffic to appear to be one source (potentially 1094 requiring acceptance and caching of multiple BTNS credentials) 1096 o the ability of multihoming to cause one network layer source of 1097 traffic to appear to be multiple sources (potentially triggering 1098 unexpected warnings and requiring re-acceptance of the same BTNS 1099 credential), and 1101 o interactions with both mobility and address ownership changes 1102 (potentially requiring controlled BTNS credential reassignment 1103 and/or invalidation). 1105 These issues are left to be addressed by possible future work on 1106 addition of "Leap of Faith" functionality to BTNS. 1108 In contrast, for CBB, credential caching and verification are usually 1109 done at the higher layer protocols or applications. Caching 1110 credentials for CBB at the BTNS level is not as important because the 1111 channel binding will bind whatever credentials are presented (new or 1112 cached) to the higher layer protocol identity. 1114 5.8. Connection Hijacking through Rekeying 1116 Each IPsec SA has a limited lifetime (defined as a time and/or byte 1117 count), and must be rekeyed or terminated when the lifetime expires. 1118 Rekeying an SA provides a small window of opportunity where an on- 1119 path attacker can step in and hijack the new SA created by rekeying 1120 by spoofing the victim during rekeying. BTNS, and particularly SAB 1121 simplify this attack by removing the need for the attacker to 1122 authenticate as the victim or via the same non-BTNS PAD entry that 1123 was used by the victim for the original SA. CBB, on the other hand, 1124 can detect such attacks by detecting the changes in the secure 1125 channel properties. 1127 This vulnerability is caused by the lack of inter-session binding or 1128 latching of IKE SAs with the corresponding credentials of the two 1129 peers. Connection latching, together with channel binding, enables 1130 such binding, but requires higher layer protocols or applications to 1131 verify consistency of identities and authentication across the two 1132 SAs. 1134 5.9. Configuration Errors 1136 BTNS does not address errors of configuration that could result in 1137 increased vulnerability; such vulnerability is already possible using 1138 "bypass" SPD entries. SPD entries that allow BTNS must be explicitly 1139 flagged, and hence can be kept separate from SPD entries that do not 1140 allow BTNS, just as "bypass" SPD entries are separate from entries 1141 that create SAs with more conventional, stronger security. 1143 6. Related Efforts 1145 There have been a number of related efforts in the IETF and elsewhere 1146 to reduce the configuration effort of deploying the Internet security 1147 suite. 1149 The IETF PKI4IPsec effort focused on providing an automatic 1150 infrastructure for the configuration of Internet security services, 1151 e.g., to assist in deploying signed certificates and CA information 1152 [9]. The IETF KINK effort focused on adapting Kerberos [13] for IKE, 1153 enabling IKE to utilize the Kerberos key distribution infrastructure 1154 rather than requiring certificates or shared private keys [18]. KINK 1155 takes advantage of an existing architecture for automatic key 1156 management in Kerberos. Opportunistic Encryption (OE) is a system for 1157 automatic discovery of hosts willing to do a BTNS-like encryption, 1158 with authentication being exchanged by leveraging existing use of the 1159 DNS [17]. BTNS differs from all three in that BTNS is intended to 1160 avoid the need for such infrastructure altogether, rather than to 1161 automate it. 1163 7. IANA Considerations 1165 There are no IANA issues in this document. 1167 This section should be removed by the RFC-Editor prior to final 1168 publication. 1170 8. Acknowledgments 1172 This document was inspired by discussions on the IETF TCPM WG about 1173 the spoofed RST attacks on BGP routers and various solutions, as well 1174 as discussions in the nfsv4 and ips WGs about how to better integrate 1175 with IPsec. The concept of BTNS was the result of these discussions 1176 as well as with USC/ISI's T. Faber, A. Falk, and B. Tung, and 1177 discussions on the IETF SAAG WG and IPsec mailing list. The authors 1178 would like to thank the members of those WGs and lists, as well as 1179 the IETF BTNS BOFs and WG and its associated ANONsec mailing list 1180 (http://www.postel.org/anonsec) for their feedback, in particular, 1181 Steve Kent, Sam Hartman, Nicolas Williams, and Pekka Savola. 1183 This document was prepared using 2-Word-v2.0.template.dot. 1185 9. References 1187 9.1. Normative References 1189 (none) 1191 9.2. Informative References 1193 [1] Aboba, B., L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz 1194 (ed.), "Extensible Authentication Protocol (EAP)," RFC-3748, 1195 June 2004 1197 [2] Aboba, B., J. Tseng, J. Walker, V. Rangan, and F. Travostino, 1198 "Securing Block Storage Protocols over IP," RFC-3723, April 1199 2004. 1201 [3] CERT Vulnerability Note VU#415294, "The Border Gateway Protocol 1202 relies on persistent TCP sessions without specifying 1203 authentication requirements," 4/20/2004. 1205 [4] Dierks, T., E. Rescorla, "The Transport Layer Security (TLS) 1206 Protocol Version 1.1," RFC-4346, April 2006. 1208 [5] Harkins, D., D. Carrel, "The Internet Key Exchange (IKE)," 1209 RFC-2409, November 1998. 1211 [6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1212 Signature Option," RFC-2385, Aug. 1998. 1214 [7] Kaufman, C. (ed.), "Internet Key Exchange (IKEv2) Protocol," 1215 RFC-4306, December 2005. 1217 [8] Kent, S., K. Seo, "Security Architecture for the Internet 1218 Protocol," RFC-4301, December 2005. 1220 [9] Korver, B., " The Internet IP Security PKI Profile of 1221 IKEv1/ISAKMP, IKEv2, and PKIX," RFC-4945, August 2007. 1223 [10] Linn, J, "Generic Security Service Application Program 1224 Interface Version 2, Update 1," RFC-2743, January 2000. 1226 [11] Melnikov, A., K. Zeilenga (eds.), "Simple Authentication and 1227 Security Layer (SASL)," RFC-4422, June 2006. 1229 [12] Murphy, S., "BGP Security Vulnerabilities Analysis," RFC-4272, 1230 January 2006. 1232 [13] Neuman, C., T. Yu, K. Raeburn "The Kerberos Network 1233 Authentication Service (V5)," RFC-4120, July 2005. 1235 [14] Mostkowitz, R., P. Nikander, P. Jokela (ed.), T. Henderson, 1236 "Host Identity Protocol," RFC-5201, April 2008. 1238 [15] Ramaiah, A., R Stewart, M. Dalal, "Improving TCP's Robustness 1239 to Blind In-Window Attacks," (work in progress), 1240 draft-ietf-tcpm-tcpsecure-09, January 2008. 1242 [16] Recio, R., B. Metzler, P. Culley, J. Hilland, D. Garcia, "A 1243 Remote Direct Memory Access Protocol Specification," RFC-5040, 1244 October 2007. 1246 [17] Richardson, M., D. Redelmeier, "Opportunistic Encryption using 1247 The Internet Key Exchange (IKE)," RFC-4322, December 2005. 1249 [18] Sakane, S., K. Kameda, M. Thomas, J. Vilhuber, " Kerberized 1250 Internet Negotiation of Keys (KINK)," RFC 4430, March 2006. 1252 [19] Satran, J., K. Meth, C. Sapuntzakis, M. Chadalapaka, E. 1253 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 1254 RFC-3720, April 2004. 1256 [20] Shah, H., J. Pinkerton, R. Recio, P. Culley, "Direct Data 1257 Placement over Reliable Transports," RFC-5041, October 2007. 1259 [21] Shepler, S., B. Callaghan, D. Robinson, R. Thurlow, C., Beame, 1260 M. Eisler, D. Noveck, "Network File System (NFS) version 4 1261 Protocol," RFC-3530, April 2003. 1263 [22] Stewart, R. (ed.), "Stream Control Transmission Protocol," 1264 RFC-4960, September 2007. 1266 [23] TCP SYN-cookies, http://cr.yp.to/syncookies.html 1268 [24] Touch, J., "Defending TCP Against Spoofing Attacks," RFC-4953, 1269 July 2007. 1271 [25] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1272 Option," (work in progress), draft-ietf-tcpm-tcp-auth-opt-00, 1273 November 2007. 1275 [26] Williams, N., "IPsec Channels: Connection Latching," (work in 1276 progress), draft-ietf-btns-connection-latching-07, April 2008. 1278 [27] Williams, N., "On the Use of Channel Bindings to Secure 1279 Channels," RFC-5056, November 2007. 1281 [28] Williams, N., M. Richardson, "Better-Than-Nothing-Security: An 1282 Unauthenticated Mode of IPsec," (work in progress), draft-ietf- 1283 btns-core-06, January 2008. 1285 [29] Ylonen, T, C. Lonvick (ed.), "The Secure Shell (SSH) Protocol 1286 Architecture," RFC-4251, January 2006. 1288 Author's Addresses 1290 Joe Touch 1291 USC/ISI 1292 4676 Admiralty Way 1293 Marina del Rey, CA 90292-6695 1294 U.S.A. 1296 Phone: +1 (310) 448-9151 1297 Email: touch@isi.edu 1299 David L. Black 1300 EMC Corporation 1301 176 South Street 1302 Hopkinton, MA 01748 1303 USA 1305 Phone: +1 (508) 293-7953 1306 Email: black_david@emc.com 1307 Yu-Shun Wang 1308 Microsoft 1309 One Microsoft Way 1310 Redmond, WA 98052 1311 U.S.A. 1313 Phone: +1 (425) 722-6980 1314 Email: yu-shun.wang@microsoft.com 1316 Intellectual Property Statement 1318 The IETF takes no position regarding the validity or scope of any 1319 Intellectual Property Rights or other rights that might be claimed to 1320 pertain to the implementation or use of the technology described in 1321 this document or the extent to which any license under such rights 1322 might or might not be available; nor does it represent that it has 1323 made any independent effort to identify any such rights. Information 1324 on the procedures with respect to rights in RFC documents can be 1325 found in BCP 78 and BCP 79. 1327 Copies of IPR disclosures made to the IETF Secretariat and any 1328 assurances of licenses to be made available, or the result of an 1329 attempt made to obtain a general license or permission for the use of 1330 such proprietary rights by implementers or users of this 1331 specification can be obtained from the IETF on-line IPR repository at 1332 http://www.ietf.org/ipr. 1334 The IETF invites any interested party to bring to its attention any 1335 copyrights, patents or patent applications, or other proprietary 1336 rights that may cover technology that may be required to implement 1337 this standard. Please address the information to the IETF at 1338 ietf-ipr@ietf.org. 1340 Disclaimer of Validity 1342 This document and the information contained herein are provided on an 1343 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1344 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1345 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1346 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1347 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1348 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1350 Copyright Statement 1352 Copyright (C) The IETF Trust (2008). 1354 This document is subject to the rights, licenses and restrictions 1355 contained in BCP 78, and except as set forth therein, the authors 1356 retain all their rights. 1358 Acknowledgment 1360 Funding for the RFC Editor function is currently provided by the 1361 Internet Society.