BTNS WG J. Touch, D. Black, Y. Wang Internet Draft USC/ISI and EMC Expires: January 2006 July 1, 2005 Problem and Applicability Statement for Better Than Nothing Security (BTNS) draft-ietf-btns-prob-and-applic-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 1, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, currently requires authentication via IKE of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, pre-shared certificates and associated asymmetric keys, or the use of Kerberos. Touch, Wang, Black Expires January 1, 2006 [Page 1] Internet-Draft BTNS Problem and Applicability July 2005 The need for authentication information and its associated identities between network layer entities can be a significant obstacle to deploying network security. This document explains the rationale for extending to the Internet network security suite to enable use of IPsec security mechanisms without full IKE authentication. These extensions are intended to protect communication "better than nothing" (BTNS) on their own (Stand Alone BTNS, or SAB), and may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate and can achieve their intended benefit. Table of Contents 1. Introduction...................................................3 1.1. Assumptions...............................................4 2. Problem Statement..............................................5 2.1. Transport Protection From Packet Spoofing.................5 2.2. Authentication at Multiple Layers.........................6 2.3. Example - Secure Socket Layer.............................7 2.4. Threat Models.............................................8 3. Applicability Statement........................................9 3.1. Uses......................................................9 3.1.1. Symmetric SAB.......................................10 3.1.2. Asymmetric SAB......................................11 3.1.3. Symmetric CBB.......................................11 3.1.4. Asymmetric CBB......................................12 3.2. Vulnerabilities..........................................12 3.3. Benefits.................................................13 4. Security Considerations.......................................13 4.1. Evaluation of Threat Models..............................14 4.2. Protections..............................................15 5. Related Work and Other Issues.................................15 5.1. Not Considered...........................................15 5.2. Other IETF Efforts.......................................15 5.3. Extensions and Other Issues..............................16 6. Acknowledgments...............................................16 7. References....................................................16 7.1. Normative References.....................................16 7.2. Informative References...................................16 Author's Addresses...............................................18 Intellectual Property Statement..................................19 Disclaimer of Validity...........................................19 Copyright Statement..............................................19 Acknowledgment...................................................20 Touch, Black, Wang Expires January 1, 2006 [Page 2] Internet-Draft BTNS Problem and Applicability July 2005 1. Introduction Internet security is provided by a variety of protocols at different layers of the protocol stack. Security at the network layer, IP, is critical to protecting both network and transport protocols, the latter because most include network identifiers in their pseudoheaders, e.g., in TCP and UDP [2][12]. The current Internet network security suite, IPsec, uses IKE, which currently relies on pre-shared or pre-deployed information to authenticate identity [3][6][9]. This pre-shared/pre-deployed state is a significant impediment to its ubiquitous use. This document describes a number of practical problems caused by the Internet security suite that depend on pre-shared or pre-deployed information for authentication, and describes "better than nothing security" (BTNS), an extension of the Internet security suite that secures communication between two parties. BTNS allows IPsec security configured by IKE in which one or both parties avoid the need to be authenticated either by a shared private key, certificate signed by a mutually-known certificate authority, or other, pre-deployed authentication infrastructure (e.g., Kerberos) [6][10]. Consider the case of transport protocols. Increases in network performance and the use of long-lived connections have resulted in increased vulnerability of connection-oriented transport protocols to attack. Such attacks can be resisted to some extent within the transport layer by performing additional validity checks, requiring additional mechanisms added to each transport protocol. More direct security can be provided, either at the transport or network layer. This security currently requires a predetermined way to authenticate the endpoints, e.g., a pre-shared secret, a certificate hierarchy with pre-shared public keys, or an external key coordination system such as Kerberos. In all cases, security can be established only after ensuring that the endpoints are definitively identified before their traffic is trusted. Also consider the case where upper layers provide authentication. Web transactions secure the server using HTTPS and SSL, where the server has a certificate authenticated by a well-known certificate authority (i.e., whose public keys are predeployed on many browsers) [3][14]. Clients typically lack such certificates, as they are prohibitively expensive either in price or effort to obtain. Current secure web transactions authenticate the client via application information, such as passwords or credit card information. Web transaction security protects the application information, but does not protect the transport layer, where connections can be interrupted by spoofed Touch, Black, Wang Expires January 1, 2006 [Page 3] Internet-Draft BTNS Problem and Applicability July 2005 traffic. The network layer lacks authentication and thus cannot use the IPsec suite, even though authentication is available at upper layers. This document suggests the need for an alternate approach to security that avoids the need for authentication at the network layer. The purpose is to protect a connection only after it has been established. In this case, BTNS allows cryptographic protection for the network and transport layers without requiring the endpoints to be strongly authenticated at the network layer, possibly coupling network layer security to higher layer protocols where strong authentication is supported. The goal of this approach to security is to protect established connections but not to protect connection establishment, while avoiding the need to deploy network layer secrets, keys, and/or identities in advance. The resulting protection is not as complete, but it would be "better than nothing security", thus the name BTNS. This document presents the overall goal that BTNS is intended to address: the desire to deploy security which avoids the need for pre- deployed authentication identities and associated secrets or keys at the network layer to achieve network layer protection which is "better than nothing." It also presents discusses the intended application of BTNS solutions, including Stand-Alone BTNS (SAB), as well as integration with authentication at higher layers of the protocol stack that still protect network and transport layer traffic, called Channel Bound BTNS (CBB). 1.1. Assumptions The problem and applicability statement for BTNS assume the use of the IP network security protocol suite, i.e., IPsec, consisting of IKE, ESP, and AH, as a reasonable platform for these extensions because they are widely deployed, comparatively modular, and are currently experiencing deployment challenges due to their dependence on mutual pre-deployed shared authentication identities and associated secrets or keys. This document considers two variants of BTNS: one which supports network protection without relying on mutual pre-deployed shared authentication identities and associated secrets or keys, and one which can be coupled with authentication higher in the protocol stack. The differences in the problem statement and applicability of both variants are addressed. Touch, Black, Wang Expires January 1, 2006 [Page 4] Internet-Draft BTNS Problem and Applicability July 2005 This document does not address what components of the IP network security protocol suite may need modification or configuration to support BTNS. Example scenarios are provided as design motivations and are not intended to be a comprehensive list. 2. Problem Statement BTNS removes the need for conventional authentication in providing network security. There are two primary motivations for doing so: to remove the need to deploy authentication information altogether (Stand Alone BTNS, or SAB), and to remove the need for redundant authentication at multiple layers (Channel Bound BTNS, or CBB). The first is further motivated by the prevalence of proposed modifications to transport layer protocols to provide protections similar to a secure network layer. 2.1. Transport Protection From Packet Spoofing TCP, like many other protocols, has been susceptible to off-path third-party attacks [14]. Such attacks rely on the increase of commodity platforms supporting public access to previously privileged resources, such as root-level access. Given such access, it is trivial for anyone to generate a packet with any header desired. This, coupled with the lack of sufficient ingress filtering to drop such spoofed traffic, has resulted in an increase in off-path third- party spoofing attacks. As a result, a number of proposed solutions have been developed, some of which modify TCP processing to defeat off-path third-party spoofs by performing additional, security checks inside the transport layer. Some of these modifications augment the transport protocol with its own security, e.g., TCP/MD5 [2]. Others modify the core TCP processing rules to make it harder for off-path attackers to inject meaningful packets, either during the initial handshake (e.g. SYNcookies) or after a connection is established (e.g., TCPsecure) [2][14]. Some of these modifications are new to TCP, but have already been incorporated into other transport protocols (e.g., SCTP) or intermediate (so-called L3.5) protocols (e.g., HIP) [10][14]. Such modifications are, at best, temporary patches to the ubiquitous vulnerability to spoofing attacks. The obvious solution to spoofing is to validate the segments of a connection, either at the transport layer (which the patch provides, weakly) or the network layer. The IPsec suite already intends to provide authentication of a network layer packet and its contents, but its deployment overhead can be prohibitive. Touch, Black, Wang Expires January 1, 2006 [Page 5] Internet-Draft BTNS Problem and Applicability July 2005 Protecting the network from spoofed packets is ultimately an issue of authentication, ensuring that a receiver's interpretation of the source of a packet is accurate. Authentication validates the identity of the source of the packet. The current IPsec suite assumes that identity is validated either by a trusted third party - e.g., the certificate authority - or by a pre-deployed shared secret. Such an identity is unique and invariant across associations (pairwise security configuration), and can be used to reject packets that are not authentic. There is weaker notion of identity, one which is bootstrapped from the session association itself. The identity doesn't mean "Bill Smith" or "owner of shared secret X2YQ", but means something more like "the end with whom I have been talking on connection #23". Such identity is not invariant across associations, but because it is invariant within an association it can still be used to provide protection for that association. BTNS thus provides a kind of intra-association integrity, a kind of relative authentication, where the identity is not authenticated across separate associations or out-of-band, but does not change during the association. This kind of BTNS is known as Stand Alone BTNS (SAB), because the protection is afforded solely by the use of BTNS extensions, without authentication from higher layers in the protocol stack. 2.2. Authentication at Multiple Layers Some protocols used on the Internet provide authentication at a layer above the transport, but rely on the IPsec suite for packet-by-packet cryptographic integrity and confidentiality services. Examples of such protocols include iSCSI and a proposed security mode for NFSv4 security [16]. With the current IPsec suite, the result is two authentications; one at the IPsec layer, using an identity for IKE and an associated secret or key, and once at the higher layer protocol using a higher layer identity and secret or key. End-node software is then responsible for making sure that the identities used for these two authentications are consistent in some fashion, an authorization policy decision. In principle a single authentication should suffice, removing the need for: o the second authentication o configuration and management of the identities and secrets or keys for the second authentication Touch, Black, Wang Expires January 1, 2006 [Page 6] Internet-Draft BTNS Problem and Applicability July 2005 o determining in some fashion that the two authentications are consistent (and potential vulnerabilities if this is not done) IPsec is not always present for these higher layer protocols, and even when present, will not always be used. Hence, if there is a choice, the higher layer protocol authentication is preferable as it will always be available for use independent of IPsec. This is complicated by the fact that IPsec must set up its security association before the higher layer protocol can send any traffic. A "better than nothing" security approach to IPsec can address this problem by setting up IPsec without an authentication and then extending the higher layer authentication to check that the two ends of the higher layer protocol session are on two ends of the same security association, via some sort of check of the identity of the security association. This check is referred to as "channel binding", thus the name Channel Bound BTNS (CBB) [21]. Channel binding must be done in a fashion that prevents a man-in-the-middle from changing the security association identity when it is checked and from causing two different security associations to have the same identity. Adding the security association identifier to authentication mechanisms based on one-way hashes, key exchanges, or (public key) cryptographic signatures are three means by which channel binding can be accomplished with man-in-the-middle resistance. This requires that the security association identifier be the same at both ends of the security association [21]. 2.3. Example - Secure Socket Layer HTTPS is a good example of an ubiquitous Internet security mechanism, providing application-layer security for web client/server communication. It consists of HTTP over SSL/TLS, which, like IKE, relies on X.509 certificates and associated certificate authorities (CAs) to identify parties [3][14]. In contrast to IKE, SSL can be used where one or both parties use certificates which are not authenticated by CAs preshared by those parties. Security may remain unauthenticated, or may be further authenticated at the application layer. Consider the case of an individual accessing a corporate website to purchase a product. Communication to the website is encrypted, based on certificates on both the corporate and individual sides. The corporate certificate is typically signed by a well-known CA, one of a set whose public keys are predeployed with most modern web browsers. The individual's certificate is only self-signed, to avoid the expense of registering with a CA. Touch, Black, Wang Expires January 1, 2006 [Page 7] Internet-Draft BTNS Problem and Applicability July 2005 The corporate website agrees to communicate with the individual's web browser even though the individual's identity has not yet been established. In some cases, the individual's identity is later verified at the application layer by confirming mutually shared information (mother's maiden name, an account number), or by using a protected preshared secret (password, PIN, etc.). In some cases, the individual's identity is never confirmed. Regardless of whether identity is confirmed later (by analogue, as in CBB) or not at all (by analogue, as in SAB), the communication is protected because of the use of unauthenticated security. The protection is persistent within a connection, but not necessarily between connections - which is why passwords are used to access recently visited sites. Such systems are widely deployed asymmetrically for the web, and symmetrically for e-mail. The kind of protections afforded by these examples of SSL are the inspiration for BTNS. BTNS differs from SSL in that it protects the network and transport layer, whereas SSL protects the application layer. BTNS can thus protect TCP connections from spoofed packets that are low-effort attacks that interfere with the connection itself, which SSL cannot. 2.4. Threat Models The following is a brief summary of the threat models of BTNS. A more detailed assessment is provided in the Security Considerations section of this document. BTNS is intended to protect sessions from a variety of threats, including man-in-the-middle after key exchange, other on-path attacks after key exchange, and off-path attacks. It is intended to protect the contents of a session once established using a "leap of faith" during session establishment, but does not protect session establishment itself. BTNS is not intended to protect the key exchange itself, so this presents an opportunity for a man-in-the-middle attack or a well- timed attack from other sources. Stand-alone BTNS is not intended to protect the endpoint from nodes masquerading as legitimate clients but rather to raise the level of effort of an attack to that of emulating a client. BTNS together with authentication from higher layers in the stack can protect from such masquerading, depending on how the authentication is coupled with the BTNS associations, and at a later point in the protocol exchange. BTNS is also not intended to protect from DOS overload of the CPU load of verification, nor is it intended to protect from user misconfiguration. These final assumptions are the same as that of the Touch, Black, Wang Expires January 1, 2006 [Page 8] Internet-Draft BTNS Problem and Applicability July 2005 IP network protocol security suite. Finally, manual keying is not considered in this document. 3. Applicability Statement BTNS is intended to provide network and transport protection in the absence of network layer authentication, whether alone (stand-alone) or in conjunction with application authentication. Recall that the former is called Stand Alone BTNS (SAB), and the latter Channel Bound BTNS (CBB). BTNS protects associations once established, but does not itself limit with whom associations are made. It is generally appropriate for services open to the public but for which protected associations are desired, or for services that can be authenticated at higher layers in the protocol stack. BTNS reduces vulnerability to attacks after associations have been established by parties not participating in the association. This helps protect systems from low-effort attacks on sessions or connections involving higher levels of resources. BTNS increases vulnerability to overloading, which can be the result of legitimate flash crowds or from zombies posing as clients. Although BTNS should be used only for public services, it can provide some level of protection for private services if the alternative is no protection at all. 3.1. Uses BTNS is intended for use for public services (SAB) or for private services that can be authenticated by higher layer protocols (CBB). It can also be used either symmetrically, where both parties lack network layer authentication information, or asymmetrically, where only one party is lacking. There a number of cases to consider, based on the matrix of SAB, CBB, and conventional authentication (denoted as IKE below); note that these are classified by the weaker side of the authentication, where SAB is the weakest, CBB is less weak, and IKE is the strongest: Touch, Black, Wang Expires January 1, 2006 [Page 9] Internet-Draft BTNS Problem and Applicability July 2005 | IKE | SAB | CBB | ----+-----------+-----------+-----------+ | | | | IKE | IKE | A-SAB | AI-CBB | | | | | ----+-----------+-----------+-----------+ | | | | SAB | A-SAB | S-SAB | AS-CBB | | | | | ----+-----------+-----------+-----------+ | | | | CBB | AI-CBB | AS-CBB | S-CBB | | | | | ----+-----------+-----------+-----------+ 1. IKE: both sides possess conventional, IKE-supported authentication 2. Symmetric SAB (S-SAB): both sides lack network layer authentication information (and lack or do not use higher layer authentication) 3. Asymmetric SAB (A-SAB): one side lacks network layer authentication information (and lacks or does not use higher layer authentication), but the other possesses it 4. Symmetric CBB (S-CBB): both sides lack network layer authentication information, and both possess authentication at a higher layer in the protocol stack 5. Asymmetric CBB (A-CBB): one side lacks network layer authentication information and possesses authentication at a higher layer in the protocol stack; there are two variants, Asymmetric IKE CBB(AI-CBB) where the other side possesses conventional IKE-supported authentication, and asymmetric stand- alone CBB (AS-CBB), where the other side lacks network layer authentication information and lacks authentication at higher layers The following is a discussion of each of these use cases. Vulnerabilities and benefits are discussed in later subsections of this section separately. 3.1.1. Symmetric SAB Symmetric SAB (S-SAB) assumes that both parties lack network layer authentication information and that authentication is not available Touch, Black, Wang Expires January 1, 2006 [Page 10] Internet-Draft BTNS Problem and Applicability July 2005 from higher layer protocols. S-SAB can still protect network and transport protocols, but does not provide authentication at all. It is useful where large files or long connections would benefit from not being interrupted by DOS attacks, but where the particular endpoint identities are not important. Peer-to-peer networks could utilize S-SAB because no peer need be privileged and preregistered at any layer in the stack. S-SAB protects all transport protocols between two peers, which is convenient because peer nets may test a variety of transport protocols in order to traverse NATs and firewalls. Public services, such as web servers, may also use S-SAB when their identity need not be authenticated to clients, but where the communication would benefit from protection. Such servers might provide large files, either unvalidated or validated by other means (e.g., published MD5 hashes). Downloads of these large files present a target for off-path attacks, which could be reduced by the use of S-SAB. S-SAB may also be useful for protecting the transport of voice-over-IP (VoIP) between peers, such as direct calls between VoIP clients. 3.1.2. Asymmetric SAB Asymmetric SAB (A-SAB) allows one party lacking network layer authentication information to establish associations with another which possesses authentication, the latter by any means supported by existing IKE. Asymmetric SAB is useful for protecting the transport connections for public services on the Internet, e.g., commercial web servers, DNS, etc. In these cases, the server is typically authenticated by a widely known CA, as is done with SSL, but the clients need not be authenticated. A-SAB also secures transport for streaming media as would be used between a VoIP client and the commercial VoIP provider, or to view broadcast streaming such as webcasts for remote education and entertainment. 3.1.3. Symmetric CBB Symmetric CCB (S-CCB) allows hosts lacking network layer authentication information to utilize authentication at higher layers in the protocol stack. Touch, Black, Wang Expires January 1, 2006 [Page 11] Internet-Draft BTNS Problem and Applicability July 2005 Such authentication already occurs during web transactions to sites whose certificates are self-signed or signed by untrusted CAs; web clients ask "do you want to trust this certificate for this session," e.g. S-CCB could support challenge/response PINs, such as used by S/Key in software or copy protection dongles. 3.1.4. Asymmetric CBB Asymmetric CBB (A-CBB) allows one host lacking network layer authentication information to later authenticate itself using higher layers in the protocol stack. A-CBB has variants depending on whether the other side is authenticated at the network layer using conventional IKE-supported means (AI-CBB), authenticated at higher layers using CBB (symmetric CBB, or S-CBB), or protected but not authenticated using SAB (AS-CBB). Most of the A-CBB variants are useful for securing remote access with unidirectional passwords, such as for FTP and email, to avoid sending cleartext passwords prior to login, but where application security is not available - e.g., for legacy applications. Which variant is appropriate depends on the sensitivity of the passwords; most would tend to be used with S-CBB or AI-CBB, where the server is authenticated before the client presents the password. AS-CBB is useful for obtaining authenticated data from a public source, where client identity is irrelevant but server identity is. 3.2. Vulnerabilities The vulnerabilities presented by BTNS depends on which variant is supported on the two ends of an association. Hosts connecting to BTNS hosts are vulnerable to communicating to a masquerader throughout the association for SAB, or until higher layers provide additional authentication for CBB. This is a deliberate design tradeoff; in BTNS, network and transport layer access is no longer gated by the network identity of the other host, so this opens hosts to masquerading and flash crowd attacks. Conversely, BTNS secures connections to hosts that cannot authenticate at the network layer, so the network and transport layers are more protected. Lacking network layer authentication information, other means must be used to protect local resources. Filters can be used to limit which interfaces, address ranges, and port ranges can access BTNS-enabled services. Rate limiting can further restrict resource usage. For SAB, these protections need to be considered throughout associations, whereas for CBB they need be present only until higher layer protocols provide the missing authentication. CCB also relies on the Touch, Black, Wang Expires January 1, 2006 [Page 12] Internet-Draft BTNS Problem and Applicability July 2005 effectiveness of the binding of higher layer authentication to the BTNS network association. 3.3. Benefits BTNS protects network and transport layers without requiring network layer authentication information. It can be deployed without configuration or pre-shared information, and protects the entire variety of transport protocols using a single mechanism. BTNS raises the level of effort for a network or transport attack. Casual, simple packet attacks need to be augmented to full associations and connection establishment for SAB, so that an attacker must perform as much work as regular host. SAB thus raises the effort for a DDOS attack to that of emulating a flash crowd. For public services, there may be no way to distinguish such a DDOS attack from a legitimate flash crowd anyway. BTNS also allows individual associations to be private without requiring predeployed authentication. We anticipate that it will use the original Diffie-Hellman exchange to establish pairwise private keys between ends of an association, effectively omitting the authentication phase currently used in IKE. As such, associations will be private, as well as protected. 4. Security Considerations Although security considerations are discussed throughout this document, there are several issues to be addressed regarding when and where to use BTNS: 1. avoiding interference with conventional network layer authentication 2. increased load on IPsec to reject spoofed traffic 3. integration with higher-layer authentication (for CBB) 4. exposure to anonymous access (for SAB) As with any aspect of network security, the use of BTNS must not interfere with conventional security services. It must be possible to limit BTNS to specific interfaces, addresses, protocols, and/or ports much the same way it is already possible to skip network security based on these parameters. It is incumbent on the system administrators to deploy BTNS only where safe, preferably as a substitute to the use of "bypass" which avoids network security Touch, Black, Wang Expires January 1, 2006 [Page 13] Internet-Draft BTNS Problem and Applicability July 2005 altogether. In summary, BTNS should be used only as a substitute for no security, rather than as a substitute for stronger security. The use of BTNS means that more traffic will use cryptographic transforms. Receivers will observe increased processing load in verifying incoming traffic as a result. Although this may itself present a substantial impediment to deployment, it is a challenge to all cryptographically protected communication systems. The use of crypto increases the load on those verifying it; we do not consider the impact that BTNS has on such load simply by encouraging the use of security. Where BTNS is integrated with higher layer authentication, i.e., CBB, special care must be taken to avoid undue resource use before higher layer authentication is established. Further, the ways in which BTNS is integrated with the higher layer protocol must take into consideration vulnerabilities that could be introduced in the APIs between these two systems or in the information that they share. Finally, the use of SAB necessary implies that a service is being offered for public access, since network layer authentication information is not available. SAB must not be deployed on services that are not intended to be publicly available. 4.1. Evaluation of Threat Models BTNS is intended to protect the network and transport layer between two parties after an association is established. SAB is not intended to protect to whom associations are established based on authenticated identity. CBB does not protect with whom associations are established initially, but allows higher layer protocols that provide authentication to couple to network layer security after the association is established, at which time the association can be adjusted accordingly. BTNS does not protect from man-in-the-middle attacks during key exchange during association establishment. SAB in particular is intended for use for publicly available services, and CBB may also be used in that capacity. In those cases, neither protects from overload due to flash crowds or DDOS attacks posing as flash crowds. BTNS does not address attacks to the association establishment key exchange, which can be substantial for flash crowds of public services of SAB or for CBB until higher layer authentication is established. Touch, Black, Wang Expires January 1, 2006 [Page 14] Internet-Draft BTNS Problem and Applicability July 2005 BTNS does not address the increased load on the system that the use of IPsec security services will incur, either for processing legitimate traffic or for rejecting attack traffic. When channel binding is used with BTNS, a man-in-the-middle attack on IPsec is discovered later than if IKE authentication were used. A man in the middle cannot subvert IKE authentication, and hence an attempt to attack it via use of two separate security associations will cause an IKE authentication failure. In contrast, with BTNS and channel binding, the IKE authentication will succeed, and the security association will be set up, only to have the higher layer authentication fail after more resources have been invested in this session. Nonetheless, this is an improvement over the alternative of minimizing the configuration of IPsec by using a group pre-shared key, which provides no defense against man-in-the-middle attacks among the nodes sharing the key. 4.2. Protections BTNS does protect from man-in-the-middle attacks after the initial association is established. Man-in-the-middle during association establishment for CBB can be detected via channel binding with higher layer authentication. BTNS protects the network and transport layer from on-path non-man- in-the-middle (i.e., snooping) and from off-path attacks. This helps especially protect transport connections from attack. 5. Related Work and Other Issues 5.1. Not Considered BTNS does not (at this time) consider the impact of mobility or multihoming on the capabilities it intends to provide. BTNS does not consider the impact of NAT or NAPT on the capabilities it intends to provide, except as are already addressed by the current Internet network security suite. 5.2. Other IETF Efforts There are a number of related efforts in the IETF and elsewhere to reduce the configuration effort of deploying the Internet security suite. PKI4IPsec is an IETF WG focused on providing an automatic infrastructure for the configuration of Internet security services, Touch, Black, Wang Expires January 1, 2006 [Page 15] Internet-Draft BTNS Problem and Applicability July 2005 e.g., to assist in deploying signed certificates and CA information [6]. The IETF KINK WG is focused on adapting Kerberos for IKE, enabling IKE to utilize the Kerberos key distribution infrastructure rather than requiring certificates signed by CAs or shared private keys [6]. KINK takes advantage of an existing architecture for automatic key management in Kerberos. Opportunistic Encryption (OE) is a system for automating authentication infrastructure by leveraging the existing use of the DNS [14]. BTNS differs from all three in that BTNS is intended to avoid the need for such infrastructure altogether, rather than to automate it. Finally, BTNS does not address a number of existing challenges to using the Internet network security suite. DOS attacks that involve overloading endpoints with invalid signatures are not addressed, as they are a natural aspect of using security and BTNS does not create or amplify that aspect per se, except to possibly encourage broader use of security. BTNS does not address errors of configuration that could result in increased vulnerability; such vulnerability is already possible using "bypass". We presume that associations using BTNS will be separated from associations with more conventional, stronger security just as "bypass" is currently separated from those associations. 5.3. Extensions and Other Issues One extension of particular interest is the ability to retain association "identity" across multiple associations, i.e., to be able to know when a host is communicating with a host it has had a previous BTNS association with. Such capabilities are already used in SSL applications, e.g., for web clients and email access. 6. Acknowledgments 7. References 7.1. Normative References (none) 7.2. Informative References [1] Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, "DNS Security Introduction and Requirements," RFC-4033, Mar. 2005. Touch, Black, Wang Expires January 1, 2006 [Page 16] Internet-Draft BTNS Problem and Applicability July 2005 [2] Dalal, M., (ed.), "Improving TCP's Robustness to Blind In- Window Attacks," (work in progress), draft-ietf-tcpm-tcpsecure- 03.txt, May 2005. [3] Frier, A., P. Karlton, P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. [4] Harkins, D., D. Carrel, "The Internet Key Exchange (IKE)," RFC- 2409, Nov. 1998. [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option," RFC-2385, Aug. 1998. [6] IETF KINK WG web pages, http://www.ietf.org/html.charters/kink- charter.html [7] IETF PKI4IPSEC WG web pages, http://www.ietf.org/html.charters/pki4ipsec-charter.html [8] Kent, S., R. Atkinson, "Security Architecture for the Internet Protocol," RFC-2401, Nov. 1998. [9] Kent, S., K. Seo, "Security Architecture for the Internet Protocol," (work in progress), draft-ietf-ipsec-rfc2401bis-06, Mar. 2005. [10] Kohl, J., C. Neuman, "The Kerberos Network Authentication Service (V5)," RFC-1510, Sep. 1993. [11] Mostkowitz, R., P. Nikander, P. Jokela (ed.), T. Henderson, "Host Identity Protocol," draft-ietf-hip-base-03, June 2005. [12] Postel, J., "User Datagram Protocol," RFC-768 / STD-6, Aug. 1980. [13] Postel, J., (ed.), "Transmission Control Protocol," RFC-793 / STD-7, Sept. 1981. [14] Rescorla, E., "HTTP Over TLS," RFC-2818, May 2000. [15] Richardson, M., "Opportunistic Encryption using The Internet Key Exchange (IKE)," (work in progress), draft-richardson- ipsec-opportunistic-17.txt, Jan. 2005. [16] Satran, J., K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. Touch, Black, Wang Expires January 1, 2006 [Page 17] Internet-Draft BTNS Problem and Applicability July 2005 [17] Shepler, S., B. Callaghan, D. Robinson, R. Thurlow, C., Beame, M. Eisler, D. Noveck, "Network File System (NFS) version 4 Protocol," RFC-3530, April, 2003. [18] Stewart, R., et al., "Stream Control Transmission Protocol," RFC-2960, Oct. 2000. [19] TCP SYN-cookies, http://cr.yp.to/syncookies.html [20] Touch, J., "Defending TCP Against Spoofing Attacks," (work in progress), draft-ietf-tcpm-tcp-antispoof-01.txt, Apr. 2005. [21] Williams, N., "On the Use of Channel Bindings to Secure Channels," (work in progress), draft-ietf-nfsv4-channel- bindings-03.txt, Feb. 2005. [22] Copy protection dongles [23] S/Key Author's Addresses Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A. Phone: +1 (310) 448-9151 Email: touch@isi.edu David Black EMC Corporation 176 South Street Hopkinton, MA 01748 USA Phone: +1 (508) 293-7953 Email: black_david@emc.com Touch, Black, Wang Expires January 1, 2006 [Page 18] Internet-Draft BTNS Problem and Applicability July 2005 Yu-Shun Wang USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A. Phone: +1 (310) 448-8742 Email: yushunwa@isi.edu Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). Touch, Black, Wang Expires January 1, 2006 [Page 19] Internet-Draft BTNS Problem and Applicability July 2005 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Touch, Black, Wang Expires January 1, 2006 [Page 20]