idnits 2.17.1 draft-ietf-btns-prob-and-applic-00.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 on line 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 854. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 874), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 1, 2005) is 6873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 739, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 761, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 771, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 777, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 782, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 790, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 794, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 797, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 799, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 806, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 808, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-03 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '4') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '5') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '8') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '10') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '13') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '14') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3720 (ref. '16') (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 3530 (ref. '17') (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '18') (Obsoleted by RFC 4960) == Outdated reference: A later version (-06) exists of draft-ietf-tcpm-tcp-antispoof-01 == Outdated reference: A later version (-04) exists of draft-ietf-nfsv4-channel-bindings-03 Summary: 6 errors (**), 0 flaws (~~), 20 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 and EMC 3 Expires: January 2006 July 1, 2005 5 Problem and Applicability Statement 6 for Better Than Nothing Security (BTNS) 7 draft-ietf-btns-prob-and-applic-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 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 January 1, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 The Internet network security protocol suite, IPsec, consisting of 42 IKE, ESP, and AH, currently requires authentication via IKE of 43 network layer entities to bootstrap security. This authentication can 44 be based on mechanisms such as pre-shared symmetric keys, pre-shared 45 certificates and associated asymmetric keys, or the use of Kerberos. 47 The need for authentication information and its associated identities 48 between network layer entities can be a significant obstacle to 49 deploying network security. This document explains the rationale for 50 extending to the Internet network security suite to enable use of 51 IPsec security mechanisms without full IKE authentication. These 52 extensions are intended to protect communication "better than 53 nothing" (BTNS) on their own (Stand Alone BTNS, or SAB), and may be 54 useful in providing network layer security that can be authenticated 55 by higher layers in the protocol stack, called Channel Bound BTNS 56 (CBB). This document also explains situations in which use of SAB and 57 CBB extensions are appropriate and can achieve their intended 58 benefit. 60 Table of Contents 62 1. Introduction...................................................3 63 1.1. Assumptions...............................................4 64 2. Problem Statement..............................................5 65 2.1. Transport Protection From Packet Spoofing.................5 66 2.2. Authentication at Multiple Layers.........................6 67 2.3. Example - Secure Socket Layer.............................7 68 2.4. Threat Models.............................................8 69 3. Applicability Statement........................................9 70 3.1. Uses......................................................9 71 3.1.1. Symmetric SAB.......................................10 72 3.1.2. Asymmetric SAB......................................11 73 3.1.3. Symmetric CBB.......................................11 74 3.1.4. Asymmetric CBB......................................12 75 3.2. Vulnerabilities..........................................12 76 3.3. Benefits.................................................13 77 4. Security Considerations.......................................13 78 4.1. Evaluation of Threat Models..............................14 79 4.2. Protections..............................................15 80 5. Related Work and Other Issues.................................15 81 5.1. Not Considered...........................................15 82 5.2. Other IETF Efforts.......................................15 83 5.3. Extensions and Other Issues..............................16 84 6. Acknowledgments...............................................16 85 7. References....................................................16 86 7.1. Normative References.....................................16 87 7.2. Informative References...................................16 88 Author's Addresses...............................................18 89 Intellectual Property Statement..................................19 90 Disclaimer of Validity...........................................19 91 Copyright Statement..............................................19 92 Acknowledgment...................................................20 94 1. Introduction 96 Internet security is provided by a variety of protocols at different 97 layers of the protocol stack. Security at the network layer, IP, is 98 critical to protecting both network and transport protocols, the 99 latter because most include network identifiers in their 100 pseudoheaders, e.g., in TCP and UDP [2][12]. The current Internet 101 network security suite, IPsec, uses IKE, which currently relies on 102 pre-shared or pre-deployed information to authenticate identity 103 [3][6][9]. This pre-shared/pre-deployed state is a significant 104 impediment to its ubiquitous use. 106 This document describes a number of practical problems caused by the 107 Internet security suite that depend on pre-shared or pre-deployed 108 information for authentication, and describes "better than nothing 109 security" (BTNS), an extension of the Internet security suite that 110 secures communication between two parties. BTNS allows IPsec security 111 configured by IKE in which one or both parties avoid the need to be 112 authenticated either by a shared private key, certificate signed by a 113 mutually-known certificate authority, or other, pre-deployed 114 authentication infrastructure (e.g., Kerberos) [6][10]. 116 Consider the case of transport protocols. Increases in network 117 performance and the use of long-lived connections have resulted in 118 increased vulnerability of connection-oriented transport protocols to 119 attack. Such attacks can be resisted to some extent within the 120 transport layer by performing additional validity checks, requiring 121 additional mechanisms added to each transport protocol. More direct 122 security can be provided, either at the transport or network layer. 123 This security currently requires a predetermined way to authenticate 124 the endpoints, e.g., a pre-shared secret, a certificate hierarchy 125 with pre-shared public keys, or an external key coordination system 126 such as Kerberos. In all cases, security can be established only 127 after ensuring that the endpoints are definitively identified before 128 their traffic is trusted. 130 Also consider the case where upper layers provide authentication. Web 131 transactions secure the server using HTTPS and SSL, where the server 132 has a certificate authenticated by a well-known certificate authority 133 (i.e., whose public keys are predeployed on many browsers) [3][14]. 134 Clients typically lack such certificates, as they are prohibitively 135 expensive either in price or effort to obtain. Current secure web 136 transactions authenticate the client via application information, 137 such as passwords or credit card information. Web transaction 138 security protects the application information, but does not protect 139 the transport layer, where connections can be interrupted by spoofed 140 traffic. The network layer lacks authentication and thus cannot use 141 the IPsec suite, even though authentication is available at upper 142 layers. 144 This document suggests the need for an alternate approach to security 145 that avoids the need for authentication at the network layer. The 146 purpose is to protect a connection only after it has been 147 established. In this case, BTNS allows cryptographic protection for 148 the network and transport layers without requiring the endpoints to 149 be strongly authenticated at the network layer, possibly coupling 150 network layer security to higher layer protocols where strong 151 authentication is supported. 153 The goal of this approach to security is to protect established 154 connections but not to protect connection establishment, while 155 avoiding the need to deploy network layer secrets, keys, and/or 156 identities in advance. The resulting protection is not as complete, 157 but it would be "better than nothing security", thus the name BTNS. 159 This document presents the overall goal that BTNS is intended to 160 address: the desire to deploy security which avoids the need for pre- 161 deployed authentication identities and associated secrets or keys at 162 the network layer to achieve network layer protection which is 163 "better than nothing." It also presents discusses the intended 164 application of BTNS solutions, including Stand-Alone BTNS (SAB), as 165 well as integration with authentication at higher layers of the 166 protocol stack that still protect network and transport layer 167 traffic, called Channel Bound BTNS (CBB). 169 1.1. Assumptions 171 The problem and applicability statement for BTNS assume the use of 172 the IP network security protocol suite, i.e., IPsec, consisting of 173 IKE, ESP, and AH, as a reasonable platform for these extensions 174 because they are widely deployed, comparatively modular, and are 175 currently experiencing deployment challenges due to their dependence 176 on mutual pre-deployed shared authentication identities and 177 associated secrets or keys. 179 This document considers two variants of BTNS: one which supports 180 network protection without relying on mutual pre-deployed shared 181 authentication identities and associated secrets or keys, and one 182 which can be coupled with authentication higher in the protocol 183 stack. The differences in the problem statement and applicability of 184 both variants are addressed. 186 This document does not address what components of the IP network 187 security protocol suite may need modification or configuration to 188 support BTNS. Example scenarios are provided as design motivations 189 and are not intended to be a comprehensive list. 191 2. Problem Statement 193 BTNS removes the need for conventional authentication in providing 194 network security. There are two primary motivations for doing so: to 195 remove the need to deploy authentication information altogether 196 (Stand Alone BTNS, or SAB), and to remove the need for redundant 197 authentication at multiple layers (Channel Bound BTNS, or CBB). The 198 first is further motivated by the prevalence of proposed 199 modifications to transport layer protocols to provide protections 200 similar to a secure network layer. 202 2.1. Transport Protection From Packet Spoofing 204 TCP, like many other protocols, has been susceptible to off-path 205 third-party attacks [14]. Such attacks rely on the increase of 206 commodity platforms supporting public access to previously privileged 207 resources, such as root-level access. Given such access, it is 208 trivial for anyone to generate a packet with any header desired. 209 This, coupled with the lack of sufficient ingress filtering to drop 210 such spoofed traffic, has resulted in an increase in off-path third- 211 party spoofing attacks. As a result, a number of proposed solutions 212 have been developed, some of which modify TCP processing to defeat 213 off-path third-party spoofs by performing additional, security checks 214 inside the transport layer. 216 Some of these modifications augment the transport protocol with its 217 own security, e.g., TCP/MD5 [2]. Others modify the core TCP 218 processing rules to make it harder for off-path attackers to inject 219 meaningful packets, either during the initial handshake (e.g. 220 SYNcookies) or after a connection is established (e.g., TCPsecure) 221 [2][14]. Some of these modifications are new to TCP, but have already 222 been incorporated into other transport protocols (e.g., SCTP) or 223 intermediate (so-called L3.5) protocols (e.g., HIP) [10][14]. 225 Such modifications are, at best, temporary patches to the ubiquitous 226 vulnerability to spoofing attacks. The obvious solution to spoofing 227 is to validate the segments of a connection, either at the transport 228 layer (which the patch provides, weakly) or the network layer. The 229 IPsec suite already intends to provide authentication of a network 230 layer packet and its contents, but its deployment overhead can be 231 prohibitive. 233 Protecting the network from spoofed packets is ultimately an issue of 234 authentication, ensuring that a receiver's interpretation of the 235 source of a packet is accurate. Authentication validates the identity 236 of the source of the packet. The current IPsec suite assumes that 237 identity is validated either by a trusted third party - e.g., the 238 certificate authority - or by a pre-deployed shared secret. Such an 239 identity is unique and invariant across associations (pairwise 240 security configuration), and can be used to reject packets that are 241 not authentic. 243 There is weaker notion of identity, one which is bootstrapped from 244 the session association itself. The identity doesn't mean "Bill 245 Smith" or "owner of shared secret X2YQ", but means something more 246 like "the end with whom I have been talking on connection #23". Such 247 identity is not invariant across associations, but because it is 248 invariant within an association it can still be used to provide 249 protection for that association. 251 BTNS thus provides a kind of intra-association integrity, a kind of 252 relative authentication, where the identity is not authenticated 253 across separate associations or out-of-band, but does not change 254 during the association. This kind of BTNS is known as Stand Alone 255 BTNS (SAB), because the protection is afforded solely by the use of 256 BTNS extensions, without authentication from higher layers in the 257 protocol stack. 259 2.2. Authentication at Multiple Layers 261 Some protocols used on the Internet provide authentication at a layer 262 above the transport, but rely on the IPsec suite for packet-by-packet 263 cryptographic integrity and confidentiality services. Examples of 264 such protocols include iSCSI and a proposed security mode for NFSv4 265 security [16]. With the current IPsec 266 suite, the result is two authentications; one at the IPsec layer, 267 using an identity for IKE and an associated secret or key, and once 268 at the higher layer protocol using a higher layer identity and secret 269 or key. End-node software is then responsible for making sure that 270 the identities used for these two authentications are consistent in 271 some fashion, an authorization policy decision. In principle a 272 single authentication should suffice, removing the need for: 274 o the second authentication 276 o configuration and management of the identities and secrets or keys 277 for the second authentication 279 o determining in some fashion that the two authentications are 280 consistent (and potential vulnerabilities if this is not done) 282 IPsec is not always present for these higher layer protocols, and 283 even when present, will not always be used. Hence, if there is a 284 choice, the higher layer protocol authentication is preferable as it 285 will always be available for use independent of IPsec. This is 286 complicated by the fact that IPsec must set up its security 287 association before the higher layer protocol can send any traffic. 289 A "better than nothing" security approach to IPsec can address this 290 problem by setting up IPsec without an authentication and then 291 extending the higher layer authentication to check that the two ends 292 of the higher layer protocol session are on two ends of the same 293 security association, via some sort of check of the identity of the 294 security association. This check is referred to as "channel binding", 295 thus the name Channel Bound BTNS (CBB) [21]. Channel binding must be 296 done in a fashion that prevents a man-in-the-middle from changing the 297 security association identity when it is checked and from causing two 298 different security associations to have the same identity. Adding 299 the security association identifier to authentication mechanisms 300 based on one-way hashes, key exchanges, or (public key) cryptographic 301 signatures are three means by which channel binding can be 302 accomplished with man-in-the-middle resistance. This requires that 303 the security association identifier be the same at both ends of the 304 security association [21]. 306 2.3. Example - Secure Socket Layer 308 HTTPS is a good example of an ubiquitous Internet security mechanism, 309 providing application-layer security for web client/server 310 communication. It consists of HTTP over SSL/TLS, which, like IKE, 311 relies on X.509 certificates and associated certificate authorities 312 (CAs) to identify parties [3][14]. In contrast to IKE, SSL can be 313 used where one or both parties use certificates which are not 314 authenticated by CAs preshared by those parties. Security may remain 315 unauthenticated, or may be further authenticated at the application 316 layer. 318 Consider the case of an individual accessing a corporate website to 319 purchase a product. Communication to the website is encrypted, based 320 on certificates on both the corporate and individual sides. The 321 corporate certificate is typically signed by a well-known CA, one of 322 a set whose public keys are predeployed with most modern web 323 browsers. The individual's certificate is only self-signed, to avoid 324 the expense of registering with a CA. 326 The corporate website agrees to communicate with the individual's web 327 browser even though the individual's identity has not yet been 328 established. In some cases, the individual's identity is later 329 verified at the application layer by confirming mutually shared 330 information (mother's maiden name, an account number), or by using a 331 protected preshared secret (password, PIN, etc.). In some cases, the 332 individual's identity is never confirmed. 334 Regardless of whether identity is confirmed later (by analogue, as in 335 CBB) or not at all (by analogue, as in SAB), the communication is 336 protected because of the use of unauthenticated security. The 337 protection is persistent within a connection, but not necessarily 338 between connections - which is why passwords are used to access 339 recently visited sites. Such systems are widely deployed 340 asymmetrically for the web, and symmetrically for e-mail. The kind of 341 protections afforded by these examples of SSL are the inspiration for 342 BTNS. BTNS differs from SSL in that it protects the network and 343 transport layer, whereas SSL protects the application layer. BTNS can 344 thus protect TCP connections from spoofed packets that are low-effort 345 attacks that interfere with the connection itself, which SSL cannot. 347 2.4. Threat Models 349 The following is a brief summary of the threat models of BTNS. A more 350 detailed assessment is provided in the Security Considerations 351 section of this document. 353 BTNS is intended to protect sessions from a variety of threats, 354 including man-in-the-middle after key exchange, other on-path attacks 355 after key exchange, and off-path attacks. It is intended to protect 356 the contents of a session once established using a "leap of faith" 357 during session establishment, but does not protect session 358 establishment itself. 360 BTNS is not intended to protect the key exchange itself, so this 361 presents an opportunity for a man-in-the-middle attack or a well- 362 timed attack from other sources. Stand-alone BTNS is not intended to 363 protect the endpoint from nodes masquerading as legitimate clients 364 but rather to raise the level of effort of an attack to that of 365 emulating a client. BTNS together with authentication from higher 366 layers in the stack can protect from such masquerading, depending on 367 how the authentication is coupled with the BTNS associations, and at 368 a later point in the protocol exchange. 370 BTNS is also not intended to protect from DOS overload of the CPU 371 load of verification, nor is it intended to protect from user 372 misconfiguration. These final assumptions are the same as that of the 373 IP network protocol security suite. Finally, manual keying is not 374 considered in this document. 376 3. Applicability Statement 378 BTNS is intended to provide network and transport protection in the 379 absence of network layer authentication, whether alone (stand-alone) 380 or in conjunction with application authentication. Recall that the 381 former is called Stand Alone BTNS (SAB), and the latter Channel Bound 382 BTNS (CBB). 384 BTNS protects associations once established, but does not itself 385 limit with whom associations are made. It is generally appropriate 386 for services open to the public but for which protected associations 387 are desired, or for services that can be authenticated at higher 388 layers in the protocol stack. 390 BTNS reduces vulnerability to attacks after associations have been 391 established by parties not participating in the association. This 392 helps protect systems from low-effort attacks on sessions or 393 connections involving higher levels of resources. 395 BTNS increases vulnerability to overloading, which can be the result 396 of legitimate flash crowds or from zombies posing as clients. 397 Although BTNS should be used only for public services, it can provide 398 some level of protection for private services if the alternative is 399 no protection at all. 401 3.1. Uses 403 BTNS is intended for use for public services (SAB) or for private 404 services that can be authenticated by higher layer protocols (CBB). 405 It can also be used either symmetrically, where both parties lack 406 network layer authentication information, or asymmetrically, where 407 only one party is lacking. There a number of cases to consider, based 408 on the matrix of SAB, CBB, and conventional authentication (denoted 409 as IKE below); note that these are classified by the weaker side of 410 the authentication, where SAB is the weakest, CBB is less weak, and 411 IKE is the strongest: 413 | IKE | SAB | CBB | 414 ----+-----------+-----------+-----------+ 415 | | | | 416 IKE | IKE | A-SAB | AI-CBB | 417 | | | | 418 ----+-----------+-----------+-----------+ 419 | | | | 420 SAB | A-SAB | S-SAB | AS-CBB | 421 | | | | 422 ----+-----------+-----------+-----------+ 423 | | | | 424 CBB | AI-CBB | AS-CBB | S-CBB | 425 | | | | 426 ----+-----------+-----------+-----------+ 428 1. IKE: both sides possess conventional, IKE-supported authentication 430 2. Symmetric SAB (S-SAB): both sides lack network layer 431 authentication information (and lack or do not use higher layer 432 authentication) 434 3. Asymmetric SAB (A-SAB): one side lacks network layer 435 authentication information (and lacks or does not use higher layer 436 authentication), but the other possesses it 438 4. Symmetric CBB (S-CBB): both sides lack network layer 439 authentication information, and both possess authentication at a 440 higher layer in the protocol stack 442 5. Asymmetric CBB (A-CBB): one side lacks network layer 443 authentication information and possesses authentication at a 444 higher layer in the protocol stack; there are two variants, 445 Asymmetric IKE CBB(AI-CBB) where the other side possesses 446 conventional IKE-supported authentication, and asymmetric stand- 447 alone CBB (AS-CBB), where the other side lacks network layer 448 authentication information and lacks authentication at higher 449 layers 451 The following is a discussion of each of these use cases. 452 Vulnerabilities and benefits are discussed in later subsections of 453 this section separately. 455 3.1.1. Symmetric SAB 457 Symmetric SAB (S-SAB) assumes that both parties lack network layer 458 authentication information and that authentication is not available 459 from higher layer protocols. S-SAB can still protect network and 460 transport protocols, but does not provide authentication at all. It 461 is useful where large files or long connections would benefit from 462 not being interrupted by DOS attacks, but where the particular 463 endpoint identities are not important. 465 Peer-to-peer networks could utilize S-SAB because no peer need be 466 privileged and preregistered at any layer in the stack. S-SAB 467 protects all transport protocols between two peers, which is 468 convenient because peer nets may test a variety of transport 469 protocols in order to traverse NATs and firewalls. 471 Public services, such as web servers, may also use S-SAB when their 472 identity need not be authenticated to clients, but where the 473 communication would benefit from protection. Such servers might 474 provide large files, either unvalidated or validated by other means 475 (e.g., published MD5 hashes). Downloads of these large files present 476 a target for off-path attacks, which could be reduced by the use of 477 S-SAB. S-SAB may also be useful for protecting the transport of 478 voice-over-IP (VoIP) between peers, such as direct calls between VoIP 479 clients. 481 3.1.2. Asymmetric SAB 483 Asymmetric SAB (A-SAB) allows one party lacking network layer 484 authentication information to establish associations with another 485 which possesses authentication, the latter by any means supported by 486 existing IKE. 488 Asymmetric SAB is useful for protecting the transport connections for 489 public services on the Internet, e.g., commercial web servers, DNS, 490 etc. In these cases, the server is typically authenticated by a 491 widely known CA, as is done with SSL, but the clients need not be 492 authenticated. 494 A-SAB also secures transport for streaming media as would be used 495 between a VoIP client and the commercial VoIP provider, or to view 496 broadcast streaming such as webcasts for remote education and 497 entertainment. 499 3.1.3. Symmetric CBB 501 Symmetric CCB (S-CCB) allows hosts lacking network layer 502 authentication information to utilize authentication at higher layers 503 in the protocol stack. 505 Such authentication already occurs during web transactions to sites 506 whose certificates are self-signed or signed by untrusted CAs; web 507 clients ask "do you want to trust this certificate for this session," 508 e.g. S-CCB could support challenge/response PINs, such as used by 509 S/Key in software or copy protection dongles. 511 3.1.4. Asymmetric CBB 513 Asymmetric CBB (A-CBB) allows one host lacking network layer 514 authentication information to later authenticate itself using higher 515 layers in the protocol stack. A-CBB has variants depending on whether 516 the other side is authenticated at the network layer using 517 conventional IKE-supported means (AI-CBB), authenticated at higher 518 layers using CBB (symmetric CBB, or S-CBB), or protected but not 519 authenticated using SAB (AS-CBB). 521 Most of the A-CBB variants are useful for securing remote access with 522 unidirectional passwords, such as for FTP and email, to avoid sending 523 cleartext passwords prior to login, but where application security is 524 not available - e.g., for legacy applications. Which variant is 525 appropriate depends on the sensitivity of the passwords; most would 526 tend to be used with S-CBB or AI-CBB, where the server is 527 authenticated before the client presents the password. 529 AS-CBB is useful for obtaining authenticated data from a public 530 source, where client identity is irrelevant but server identity is. 532 3.2. Vulnerabilities 534 The vulnerabilities presented by BTNS depends on which variant is 535 supported on the two ends of an association. Hosts connecting to BTNS 536 hosts are vulnerable to communicating to a masquerader throughout the 537 association for SAB, or until higher layers provide additional 538 authentication for CBB. This is a deliberate design tradeoff; in 539 BTNS, network and transport layer access is no longer gated by the 540 network identity of the other host, so this opens hosts to 541 masquerading and flash crowd attacks. Conversely, BTNS secures 542 connections to hosts that cannot authenticate at the network layer, 543 so the network and transport layers are more protected. 545 Lacking network layer authentication information, other means must be 546 used to protect local resources. Filters can be used to limit which 547 interfaces, address ranges, and port ranges can access BTNS-enabled 548 services. Rate limiting can further restrict resource usage. For SAB, 549 these protections need to be considered throughout associations, 550 whereas for CBB they need be present only until higher layer 551 protocols provide the missing authentication. CCB also relies on the 552 effectiveness of the binding of higher layer authentication to the 553 BTNS network association. 555 3.3. Benefits 557 BTNS protects network and transport layers without requiring network 558 layer authentication information. It can be deployed without 559 configuration or pre-shared information, and protects the entire 560 variety of transport protocols using a single mechanism. 562 BTNS raises the level of effort for a network or transport attack. 563 Casual, simple packet attacks need to be augmented to full 564 associations and connection establishment for SAB, so that an 565 attacker must perform as much work as regular host. SAB thus raises 566 the effort for a DDOS attack to that of emulating a flash crowd. For 567 public services, there may be no way to distinguish such a DDOS 568 attack from a legitimate flash crowd anyway. 570 BTNS also allows individual associations to be private without 571 requiring predeployed authentication. We anticipate that it will use 572 the original Diffie-Hellman exchange to establish pairwise private 573 keys between ends of an association, effectively omitting the 574 authentication phase currently used in IKE. As such, associations 575 will be private, as well as protected. 577 4. Security Considerations 579 Although security considerations are discussed throughout this 580 document, there are several issues to be addressed regarding when and 581 where to use BTNS: 583 1. avoiding interference with conventional network layer 584 authentication 586 2. increased load on IPsec to reject spoofed traffic 588 3. integration with higher-layer authentication (for CBB) 590 4. exposure to anonymous access (for SAB) 592 As with any aspect of network security, the use of BTNS must not 593 interfere with conventional security services. It must be possible to 594 limit BTNS to specific interfaces, addresses, protocols, and/or ports 595 much the same way it is already possible to skip network security 596 based on these parameters. It is incumbent on the system 597 administrators to deploy BTNS only where safe, preferably as a 598 substitute to the use of "bypass" which avoids network security 599 altogether. In summary, BTNS should be used only as a substitute for 600 no security, rather than as a substitute for stronger security. 602 The use of BTNS means that more traffic will use cryptographic 603 transforms. Receivers will observe increased processing load in 604 verifying incoming traffic as a result. Although this may itself 605 present a substantial impediment to deployment, it is a challenge to 606 all cryptographically protected communication systems. The use of 607 crypto increases the load on those verifying it; we do not consider 608 the impact that BTNS has on such load simply by encouraging the use 609 of security. 611 Where BTNS is integrated with higher layer authentication, i.e., CBB, 612 special care must be taken to avoid undue resource use before higher 613 layer authentication is established. Further, the ways in which BTNS 614 is integrated with the higher layer protocol must take into 615 consideration vulnerabilities that could be introduced in the APIs 616 between these two systems or in the information that they share. 618 Finally, the use of SAB necessary implies that a service is being 619 offered for public access, since network layer authentication 620 information is not available. SAB must not be deployed on services 621 that are not intended to be publicly available. 623 4.1. Evaluation of Threat Models 625 BTNS is intended to protect the network and transport layer between 626 two parties after an association is established. SAB is not intended 627 to protect to whom associations are established based on 628 authenticated identity. CBB does not protect with whom associations 629 are established initially, but allows higher layer protocols that 630 provide authentication to couple to network layer security after the 631 association is established, at which time the association can be 632 adjusted accordingly. 634 BTNS does not protect from man-in-the-middle attacks during key 635 exchange during association establishment. 637 SAB in particular is intended for use for publicly available 638 services, and CBB may also be used in that capacity. In those cases, 639 neither protects from overload due to flash crowds or DDOS attacks 640 posing as flash crowds. 642 BTNS does not address attacks to the association establishment key 643 exchange, which can be substantial for flash crowds of public 644 services of SAB or for CBB until higher layer authentication is 645 established. 647 BTNS does not address the increased load on the system that the use 648 of IPsec security services will incur, either for processing 649 legitimate traffic or for rejecting attack traffic. 651 When channel binding is used with BTNS, a man-in-the-middle attack on 652 IPsec is discovered later than if IKE authentication were used. A 653 man in the middle cannot subvert IKE authentication, and hence an 654 attempt to attack it via use of two separate security associations 655 will cause an IKE authentication failure. In contrast, with BTNS and 656 channel binding, the IKE authentication will succeed, and the 657 security association will be set up, only to have the higher layer 658 authentication fail after more resources have been invested in this 659 session. Nonetheless, this is an improvement over the alternative of 660 minimizing the configuration of IPsec by using a group pre-shared 661 key, which provides no defense against man-in-the-middle attacks 662 among the nodes sharing the key. 664 4.2. Protections 666 BTNS does protect from man-in-the-middle attacks after the initial 667 association is established. Man-in-the-middle during association 668 establishment for CBB can be detected via channel binding with higher 669 layer authentication. 671 BTNS protects the network and transport layer from on-path non-man- 672 in-the-middle (i.e., snooping) and from off-path attacks. This helps 673 especially protect transport connections from attack. 675 5. Related Work and Other Issues 677 5.1. Not Considered 679 BTNS does not (at this time) consider the impact of mobility or 680 multihoming on the capabilities it intends to provide. 682 BTNS does not consider the impact of NAT or NAPT on the capabilities 683 it intends to provide, except as are already addressed by the current 684 Internet network security suite. 686 5.2. Other IETF Efforts 688 There are a number of related efforts in the IETF and elsewhere to 689 reduce the configuration effort of deploying the Internet security 690 suite. 692 PKI4IPsec is an IETF WG focused on providing an automatic 693 infrastructure for the configuration of Internet security services, 694 e.g., to assist in deploying signed certificates and CA information 695 [6]. The IETF KINK WG is focused on adapting Kerberos for IKE, 696 enabling IKE to utilize the Kerberos key distribution infrastructure 697 rather than requiring certificates signed by CAs or shared private 698 keys [6]. KINK takes advantage of an existing architecture for 699 automatic key management in Kerberos. Opportunistic Encryption (OE) 700 is a system for automating authentication infrastructure by 701 leveraging the existing use of the DNS [14]. BTNS differs from all 702 three in that BTNS is intended to avoid the need for such 703 infrastructure altogether, rather than to automate it. 705 Finally, BTNS does not address a number of existing challenges to 706 using the Internet network security suite. DOS attacks that involve 707 overloading endpoints with invalid signatures are not addressed, as 708 they are a natural aspect of using security and BTNS does not create 709 or amplify that aspect per se, except to possibly encourage broader 710 use of security. BTNS does not address errors of configuration that 711 could result in increased vulnerability; such vulnerability is 712 already possible using "bypass". We presume that associations using 713 BTNS will be separated from associations with more conventional, 714 stronger security just as "bypass" is currently separated from those 715 associations. 717 5.3. Extensions and Other Issues 719 One extension of particular interest is the ability to retain 720 association "identity" across multiple associations, i.e., to be able 721 to know when a host is communicating with a host it has had a 722 previous BTNS association with. Such capabilities are already used in 723 SSL applications, e.g., for web clients and email access. 725 727 6. Acknowledgments 729 731 7. References 733 7.1. Normative References 735 (none) 737 7.2. Informative References 739 [1] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, "DNS 740 Security Introduction and Requirements," RFC-4033, Mar. 2005. 742 [2] Dalal, M., (ed.), "Improving TCP's Robustness to Blind In- 743 Window Attacks," (work in progress), draft-ietf-tcpm-tcpsecure- 744 03.txt, May 2005. 746 [3] Frier, A., P. Karlton, P. Kocher, "The SSL 3.0 Protocol", 747 Netscape Communications Corp., Nov 18, 1996. 749 [4] Harkins, D., D. Carrel, "The Internet Key Exchange (IKE)," RFC- 750 2409, Nov. 1998. 752 [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 753 Signature Option," RFC-2385, Aug. 1998. 755 [6] IETF KINK WG web pages, http://www.ietf.org/html.charters/kink- 756 charter.html 758 [7] IETF PKI4IPSEC WG web pages, 759 http://www.ietf.org/html.charters/pki4ipsec-charter.html 761 [8] Kent, S., R. Atkinson, "Security Architecture for the Internet 762 Protocol," RFC-2401, Nov. 1998. 764 [9] Kent, S., K. Seo, "Security Architecture for the Internet 765 Protocol," (work in progress), draft-ietf-ipsec-rfc2401bis-06, 766 Mar. 2005. 768 [10] Kohl, J., C. Neuman, "The Kerberos Network Authentication 769 Service (V5)," RFC-1510, Sep. 1993. 771 [11] Mostkowitz, R., P. Nikander, P. Jokela (ed.), T. Henderson, 772 "Host Identity Protocol," draft-ietf-hip-base-03, June 2005. 774 [12] Postel, J., "User Datagram Protocol," RFC-768 / STD-6, Aug. 775 1980. 777 [13] Postel, J., (ed.), "Transmission Control Protocol," RFC-793 / 778 STD-7, Sept. 1981. 780 [14] Rescorla, E., "HTTP Over TLS," RFC-2818, May 2000. 782 [15] Richardson, M., "Opportunistic Encryption using The Internet 783 Key Exchange (IKE)," (work in progress), draft-richardson- 784 ipsec-opportunistic-17.txt, Jan. 2005. 786 [16] Satran, J., K. Meth, C. Sapuntzakis, M. Chadalapaka, E. 787 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 788 RFC 3720, April 2004. 790 [17] Shepler, S., B. Callaghan, D. Robinson, R. Thurlow, C., Beame, 791 M. Eisler, D. Noveck, "Network File System (NFS) version 4 792 Protocol," RFC-3530, April, 2003. 794 [18] Stewart, R., et al., "Stream Control Transmission Protocol," 795 RFC-2960, Oct. 2000. 797 [19] TCP SYN-cookies, http://cr.yp.to/syncookies.html 799 [20] Touch, J., "Defending TCP Against Spoofing Attacks," (work in 800 progress), draft-ietf-tcpm-tcp-antispoof-01.txt, Apr. 2005. 802 [21] Williams, N., "On the Use of Channel Bindings to Secure 803 Channels," (work in progress), draft-ietf-nfsv4-channel- 804 bindings-03.txt, Feb. 2005. 806 [22] Copy protection dongles 808 [23] S/Key 810 Author's Addresses 812 Joe Touch 813 USC/ISI 814 4676 Admiralty Way 815 Marina del Rey, CA 90292-6695 816 U.S.A. 818 Phone: +1 (310) 448-9151 819 Email: touch@isi.edu 821 David Black 822 EMC Corporation 823 176 South Street 824 Hopkinton, MA 01748 825 USA 827 Phone: +1 (508) 293-7953 828 Email: black_david@emc.com 829 Yu-Shun Wang 830 USC/ISI 831 4676 Admiralty Way 832 Marina del Rey, CA 90292-6695 833 U.S.A. 835 Phone: +1 (310) 448-8742 836 Email: yushunwa@isi.edu 838 Intellectual Property Statement 840 The IETF takes no position regarding the validity or scope of any 841 Intellectual Property Rights or other rights that might be claimed to 842 pertain to the implementation or use of the technology described in 843 this document or the extent to which any license under such rights 844 might or might not be available; nor does it represent that it has 845 made any independent effort to identify any such rights. Information 846 on the procedures with respect to rights in RFC documents can be 847 found in BCP 78 and BCP 79. 849 Copies of IPR disclosures made to the IETF Secretariat and any 850 assurances of licenses to be made available, or the result of an 851 attempt made to obtain a general license or permission for the use of 852 such proprietary rights by implementers or users of this 853 specification can be obtained from the IETF on-line IPR repository at 854 http://www.ietf.org/ipr. 856 The IETF invites any interested party to bring to its attention any 857 copyrights, patents or patent applications, or other proprietary 858 rights that may cover technology that may be required to implement 859 this standard. Please address the information to the IETF at 860 ietf-ipr@ietf.org 862 Disclaimer of Validity 864 This document and the information contained herein are provided on an 865 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 866 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 867 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 868 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 869 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 870 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 872 Copyright Statement 874 Copyright (C) The Internet Society (2005). 876 This document is subject to the rights, licenses and restrictions 877 contained in BCP 78, and except as set forth therein, the authors 878 retain all their rights. 880 Acknowledgment 882 Funding for the RFC Editor function is currently provided by the 883 Internet Society.