BTNS WG J. Touch, D. Black, Y. Wang Internet Draft USC/ISI and EMC Expires: December 2006 June 5, 2006 Problem and Applicability Statement for Better Than Nothing Security (BTNS) draft-ietf-btns-prob-and-applic-03.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 December 5, 2006. Abstract The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication via IKE of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec Touch, Wang, Black Expires December 5, 2006 [Page 1] Internet-Draft BTNS Problem and Applicability June 2006 security mechanisms without full IKE authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or 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. Table of Contents 1. Introduction...................................................3 2. Problem Statement..............................................4 2.1. Network Layer.............................................4 2.1.1. Authentication Identities............................5 2.1.2. Authentication Methods...............................5 2.1.3. Current IPsec Limits on Unauthenticated Peers........5 2.2. Upper Layer...............................................6 2.2.1. Transport Protection from Packet Spoofing............6 2.2.2. Authentication at Multiple Layers....................7 3. BTNS-IPsec Overview and Threat Models..........................9 3.1. BTNS-IPsec Overview.......................................9 3.2. BTNS-IPsec Security Services..............................9 3.3. BTNS-IPsec Modes.........................................10 4. Applicability Statement.......................................11 4.1. Symmetric SAB............................................12 4.2. Asymmetric SAB...........................................13 4.3. Symmetric CBB............................................13 4.4. Asymmetric CBB...........................................13 4.5. Benefits.................................................14 4.6. Vulnerabilities..........................................14 4.7. Summary of Uses, Vulnerabilities, and Benefits...........15 5. Security Considerations.......................................15 5.1. Threat Models and Evaluation.............................15 5.2. Interaction with Other Extant Security...................16 5.3. MITM and Masquerader Attacks.............................16 5.4. DoS Attacks and Resource Consumptions....................17 5.5. Exposure to Anonymous Access.............................18 5.6. ICMP Attacks.............................................18 5.7. Leap of Faith and Cached Credentials.....................18 5.8. Configuration Errors.....................................19 6. Other Issues and Related Efforts..............................19 6.1. NAT Traversal............................................19 6.2. Mobility and Multihoming.................................19 6.3. Related IETF Efforts.....................................19 7. IANA Considerations...........................................20 8. Acknowledgments...............................................20 9. References....................................................20 Touch, Black, Wang Expires December 5, 2006 [Page 2] Internet-Draft BTNS Problem and Applicability June 2006 9.1. Normative References.....................................20 9.2. Informative References...................................20 Author's Addresses...............................................22 Intellectual Property Statement..................................23 Disclaimer of Validity...........................................23 Copyright Statement..............................................23 Acknowledgment...................................................23 1. Introduction Network security is provided by a variety of protocols at different layers in the stack. At the network layer, the IPsec protocol suite is used to secure IP traffic. IPsec and Internet Key Exchange protocol (IKE) present an all-or-nothing alternative by providing protection from a wide array of possible threats, but requiring authentication [4][8][9][10]. In turn authentication requires deployment of network-level authentication credentials, and this can be an obstacle to IPsec usage. This document discusses the issues with regard to this dependency, and introduces "Better Than Nothing Security" (BTNS) as one solution. It also describes various modes of BTNS, and explores the characteristics of applications that will benefit from using each mode. The remainder of this section provides an overview of the background and problem scenario. The process of establishing secure network communications consists of two functions: policy and mechanism. The policy function determines "who" gets which types of security services, and the mechanism function applies the selected services to the corresponding communication traffic. The requirement for authentication credentials stems from the need to verify the "who;" i.e., to authenticate the identities of the communicating peers. There are two basic approaches to authentication: using pre-deployed information, or employing out-of-band communications. Out-of-band authentication can be done through a trusted third party, a separate channel to the peer, or the same channel but at a higher layer. It requires mechanisms and interfaces to bind the authenticated identities to the secure channels, and is out-of-scope for this document (although it may be possible to extend the channel binding mode of BTNS to work with such mechanisms). Pre-deployed information includes pre-shared secrets and credentials authenticated by trusted authorities. This form of authentication often requires manual deployment and coordination among communicating peers. Furthermore, authenticated credentials such as certificates signed by certification authorities (CA) can be cumbersome and expensive to obtain. Touch, Black, Wang Expires December 5, 2006 [Page 3] Internet-Draft BTNS Problem and Applicability June 2006 These factors increase the impact of IKE's requirement for successful authentication based on pre-deployed information before security services are offered. Consequently, users and applications often do not use IPsec to protect the network layer, but rely solely on higher layer security protocols or no security at all. As the problem statement section will describe, higher layer security protocols may not be enough to protect against some network layer spoofing attacks. To improve the situation, one could either reduce the hurdles to obtain and configure authentication information, or remove authentication at the network layer. The latter is the core idea of BTNS, which provides anonymous (unauthenticated) keying for IPsec to create Security Associations (SAs) with peers who do not possess valid authentication credentials. This requires extensions to the IPsec architecture and possibly extensions or profiles of IKE. As the new BTNS modes in IPsec relax the authentication requirement, the impacts, tradeoffs, and risks must be thoroughly understood before applying BTNS to any communications. More specifically, this document will address the issues on whether and when network layer authentication can be removed, the risks of using BTNS, and finally, the impacts to the existing IPsec architecture. The next section discusses the issues that IKE's strict requirements for network layer authentication cause for IPsec. Section 3 provides a high level overview of BTNS-IPsec, including the security services offered. Section 4 explores the applicability of BTNS-IPsec, followed by a discussion of the risks and other security considerations in Section 5. Section 6 lists other related efforts. 2. Problem Statement This section describes the problems that motivated the development of BTNS. The primary concern is that IPsec is not widely utilized despite rigorous development effort and emphasis on network security by users and organizations. There are also debates on which layer is best for securing network communications, and how security protocols at different layers should interact. The following discussion roughly categorizes these issues by layers: network layer and higher layers. 2.1. Network Layer At the network layer, one of the hurdles is to satisfy the authentication requirements of IPsec and IKE. This section investigates the problems on network layer authentication and the result of this requirement. Touch, Black, Wang Expires December 5, 2006 [Page 4] Internet-Draft BTNS Problem and Applicability June 2006 2.1.1. Authentication Identities Current IPsec authentication supports several types of identities in the Peer Authorization Database (PAD): IPv4 addresses, IPv6 addresses, DNS names, Distinguished Names, RFC 822 email addresses, and Key IDs [10]. All require either CA-signed certificates or pre- shared secrets to authenticate. These can be roughly categorized into network layer identifiers and other identifiers. The first three, IPv4/IPv6 addresses and DNS names are network layer identifiers. The main issue with IP addresses is that they are no longer stable identifiers representing the same physical systems consistently due to dynamic address assignments (DHCP) and increases in system mobility. DNS names are affected because the name to address mapping is not always up to date as a result. There are two main drawbacks with other, non-network-layer identifiers. It is too restrictive because there are likely other forms of identifiers not covered by the PAD specification. It could also result in multiple authentications on the same identifiers at different layers. In addition, the list of identifiers is not complete; some higher layer protocols use additional types of identifiers that are not supported by IPsec. These issues are also related to channel binding and will be further discussed later. 2.1.2. Authentication Methods As described earlier, CA-signed certificates and pre-shared secrets are the only methods of authentications accepted by current IPsec and IKE specifications. Pre-shared secrets require manual configuration and out-of-band communications. The verification process of CA-signed certificates is cumbersome and there may be a monetary cost in obtaining the certificates. The combination of these factors is one likely reason why IPsec is not widely used except in environments with the highest security requirements. 2.1.3. Current IPsec Limits on Unauthenticated Peers Pre-configuration only works if the peer identities are known in advance. The lack of unauthenticated IPsec modes prevents secure communications at the network layer with unauthenticated or unknown peers, even when they are subsequently authenticated in a higher layer protocol or application. The lack of a channel binding API between IPsec and upper layer protocols further forces such communications to completely bypass IPsec, leaving network layer unprotected. Touch, Black, Wang Expires December 5, 2006 [Page 5] Internet-Draft BTNS Problem and Applicability June 2006 2.2. Upper Layer For upper layers, the following discussion first focuses on whether IPsec is necessary if transport layer security is already in use. This would further motivate the need to reduce the hurdle of using IPsec. Another issue is regarding authentication at both IPsec and higher layer protocols for the same connection. 2.2.1. Transport Protection from Packet Spoofing 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 attacks. TCP, like many other protocols, is susceptible to off-path third-party attacks, such as injection of a TCP RST [19]. The network lacks comprehensive ingress filtering to drop such spoofed traffic. These attacks can affect BGP sessions between core Internet routers, and are thus of significant concern [2]. As a result, a number of proposed solutions have been developed; most of these are transport layer solutions. Some of these solutions augment the transport protocol by improving its own security, e.g., TCP/MD5 [5]. 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) [16][18]. 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) [12][17]. 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 or the network layer. The IPsec suite already provides authentication of a network layer packet and its contents, but the infrastructure required for deployment of IPsec can be prohibitive. Protecting systems 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., a certification authority - or by a pre-deployed shared secret. Such an identity is unique and invariant across associations (pair-wise security configuration), and can be used to reject packets that are not authentic. Touch, Black, Wang Expires December 5, 2006 [Page 6] Internet-Draft BTNS Problem and Applicability June 2006 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 entity with which I have been communicating 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 during the lifetime of that association. This is the core notion of identity used by BTNS. BTNS thus provides a kind of intra-association integrity, a form of authentication where the identity is not authenticated across separate associations or out-of-band, but does not change during the association. This mode of BTNS is called 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. With regard to BGP in particular, it has been understood that the use of appropriate authentication is the preferred solution [2] to TCP spoofing attacks. Supporting authentication, e.g., by using signed certificates, at one router does not solve the problem; that router is still at the mercy of all routers it peers with, as it depends on them to also support authentication. The reality is that few routers are configured to support authentication, and the result is the use of unsecured TCP for sending BGP packets. BTNS allows an individual router to relax the need for authentication, in order to enable the use of protected sessions that are not authenticated. The latter is "better than nothing" in cases where "nothing" is the alternative. 2.2.2. Authentication at Multiple Layers Some existing 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 the CCM mode for NFSv4 security [14][15]. 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 another by the higher layer protocol using a higher layer identity and secret or key. This is necessary if the identity and key formats differ between IPsec and the higher layer protocol, and because there is no standard interface to pass authentication credentials across these layers. 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: Touch, Black, Wang Expires December 5, 2006 [Page 7] Internet-Draft BTNS Problem and Applicability June 2006 o the second authentication o configuration and management of the identities and secrets or keys for the second authentication o determining in some fashion that the two authenticated identities are consistent. Note that there are significant 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. 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 establish that the higher layer protocol session is protected by a single IPsec SA. This counters man-in-the-middle (MITM) attacks on BTNS IPsec session establishment by terminating the higher layer session when such an attack occurs. This approach is based on the fact that an MITM attack on a BTNS SA will result in two different BTNS SAs, each connecting the MITM to one of the higher layer endpoints. These different SAs contribute different cryptographic binding material to the higher layer authentication, causing that authentication to fail, which should then cause the higher layer protocol session to terminate. In contrast to use of IKE authentication, this approach detects the man- in-the-middle after the SAs have been set up, and hence does not match IKE's resistance to denial of service attacks at the network layer. This check is referred in this document as "channel binding", thus the name Channel Bound BTNS (CBB) [20]. Channel binding must be done in a fashion that prevents a man-in-the-middle attack from changing the SA identity when it is checked and from causing two different SAs to have the same identity. Adding the SA 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 resistance to man-in-the- middle attacks. This requires that the SA identifier be the same at both ends of the SA [20]. Currently, the IPsec protocol suite does not define the notion of channels for channel binding. Such channels can be constructed by transport protocols layered above IP through cooperation between these protocols and IPsec, to ensure that all packets for a given channel are protected by similar SAs, where similar relates to, among Touch, Black, Wang Expires December 5, 2006 [Page 8] Internet-Draft BTNS Problem and Applicability June 2006 other things, the IDs of the peers. Interfaces between applications and transport protocols are also needed for communicating channel binding data to applications, and for applications to construct their own IPsec channels over connection-less, datagram-oriented transports. 3. BTNS-IPsec Overview and Threat Models This section provides an overview of BTNS-IPsec and the security services it offers. It also describes the modes of BTNS-IPsec. 3.1. BTNS-IPsec Overview This is an overview of what is needed to enable BTNS-IPsec. The detailed specifications of the extensions will be addressed by the relevant protocol specifications. The main update to IPsec is adding extensions to security policy that permit secure communications with un-authenticated peers. These extensions are necessary for both IPsec and IKE. For IPsec, the extension applies to the PAD, which specifies the forms of authentication for each entry ID. In addition to CA-signed X.509 certificates and pre-shared secrets, the extension adds two more categories: un-authenticated (either null or self-signed certificates) and channel binding, to support BTNS and BTNS with channel binding respectively. For IKE, the AUTH payload should be expended to allow either null payload or self-signed certificates to match the proposed PAD extensions. The changes to enable channel binding between IPsec and higher layer protocols or applications will be more complex than the policy extensions above. It will involve specifications of APIs and interactions between IPsec and higher layer protocols. This document assumes such provisions will eventually be developed, but does not address their details. 3.2. BTNS-IPsec Security Services The changes and extensions of BTNS primarily affect policy as described above. Other parts of IPsec and IKE specifications are unchanged. BTNS-IPsec does not establish nor does it require a separate IPsec context. It is integrated with any existing IPsec context in a system. The scope of BTNS-IPsec applies only to the SAs matching the policies that explicitly specify or enable BTNS modes in the PAD. All other non-BTNS policy entries, including entries in the SPD and the PAD, and any non-BTNS SAs will not be affected by BTNS- IPsec in terms of security services and requirements. Touch, Black, Wang Expires December 5, 2006 [Page 9] Internet-Draft BTNS Problem and Applicability June 2006 In principle, the result of removing authentication at the network layer is that BTNS-IPsec can establish secure connections in a fashion similar to regular IPsec and IKE, but it cannot verify or authenticate the peer identities of these secure connections. The following is a list of security services offered by IPsec protocol suite. The notes address only the differences when applied to BTNS- IPsec. 1. Access Control Because BTNS-IPsec is integrated with any existing IPsec contexts, the same access control mechanisms apply to BTNS-IPsec entries in all relevant databases except that the entity IDs for BTNS in the PAD are not authenticated. Channel bound BTNS can authenticate after the secure connection is established at the network layer. 2. Connectionless Integrity 3. Data Origin Authentication 4. Anti-Replay Protection 5. Confidentiality 6. (Limited) Traffic Flow Confidentiality For the remaining security services offered by IPsec, items 2 through 6, it is possible to establish secure connections with rogue peers in BTNS-IPsec because authentication is not required. But once a secure connection is established, the communication is afforded the same security services as regular IPsec. 3.3. BTNS-IPsec Modes The previous sections have described two ways of using BTNS: Stand- alone (SAB) or with Channel Binding (CBB). It can also be used either symmetrically, where both parties lack network layer authentication information, or asymmetrically, where only one party lacks the ability to authenticate at the network layer. There are a number of cases to consider, based on the matrix of the endpoint security capabilities of SAB, CBB, and conventional authentication (denoted as IKE below). The following table shows all the combinations based on the capabilities of the two security endpoints: Touch, Black, Wang Expires December 5, 2006 [Page 10] Internet-Draft BTNS Problem and Applicability June 2006 | 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. (*) Channel binding requires both ends to be bound in order to protect against MITM attacks. Asymmetric CBB modes are listed above for completeness. See Sec. 4.4 for further discussion. 4. Applicability Statement BTNS protects associations once established, but does not limit with which associations are made. It reduces vulnerability after associations have been established to attacks from parties not Touch, Black, Wang Expires December 5, 2006 [Page 11] Internet-Draft BTNS Problem and Applicability June 2006 participating in the association. This helps protect systems from low-effort attacks on sessions or connections involving higher levels of resources. BTNS 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 can also provide some level of protection for private services when the alternative is no protection at all (as in the case of BGP, for instance). BTNS-IPsec uses the IPsec protocol suite, therefore should not be used in situations where IPsec or IKE are unsuitable. IPsec and IKE incur additional computation overhead, and IKE further requires extra message exchanges and round-trip times to setup security associations. These are generally undesirable in environments with limited computational resources and/or high communication latencies. The following is a discussion of the applicability of each of the combinations in the above table. 4.1. Symmetric SAB Symmetric SAB (S-SAB) assumes that both parties lack network layer authentication information and that authentication is not available 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. Open services, such as web servers, and peer-to-peer networks could utilize S-SAB when their identities need not be authenticated, but where the communication would benefit from protection. Such services might provide files either not validated or validated by other means (e.g., published MD5 hashes). These transmissions present a target for off-path attacks, which could be mitigated 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. SAB is also useful in protecting any transport protocol when the endpoints decide not to deploy authentication, for whatever reason. This is the particular case for BGP TCP connections between core routers, where the protection afforded by S-SAB is better than no protection at all, even though BGP is not intended as an open service. Touch, Black, Wang Expires December 5, 2006 [Page 12] Internet-Draft BTNS Problem and Applicability June 2006 4.2. Asymmetric SAB Asymmetric SAB (A-SAB) allows one party lacking network layer authentication information to establish associations with another party that possesses authentication credentials, the latter by any applicable IKE authentication mechanisms. Asymmetric SAB is useful for protecting transport connections for open services on the Internet, e.g., commercial web servers, etc. In these cases, the server is typically authenticated by a widely known CA, as is done with TLS at the application layer, but the clients need not be authenticated. Although this may result in IPsec and TLS being used on the same connection, it is necessary because TLS does not protect from certain spoofing attacks as described in the problem statement section (e.g., TLS cannot prevent a spoofed TCP RST, as the RST is processed by TCP instead of being passed to TLS). A-SAB also secures transport for streaming media as would be used to view broadcast streaming such as webcasts for remote education and entertainment. 4.3. Symmetric CBB Symmetric CCB (S-CCB) allows hosts without network layer authentication information to cryptographically bind the BTNS-IPsec channels with authentication at higher layers. This is discussed in further detail in the channel binding specification [cite]. For higher layer protocols with full, symmetric authentication at the application layer, e.g., TLS, pre-shared keys, etc., S-CBB allows those protocols to use those credentials and exchanges to bind to BTNS-IPsec, protecting the transport and network layer protocols in addition to the application data. This enables IPsec protection at the network layer attacks (such as TCP/RST spoofing attacks) that would otherwise be vulnerable if only higher layer security protocols were applied. Note that to fully utilize S-CBB, modifications to the higher layer authentication are necessary to incorporate the channel binding information so that the binding cannot occur when an MITM attack occurs. 4.4. Asymmetric CBB As noted above, channel binding as currently proposed requires bindings at both ends of a channel. Whether channel binding will work asymmetrically and still offer some level of protection against MITM - even if asymmetric - is unclear at this time. The specific Touch, Black, Wang Expires December 5, 2006 [Page 13] Internet-Draft BTNS Problem and Applicability June 2006 applicability of this and other CBB modes will be discussed in detail in a future channel bindings document. 4.5. Benefits BTNS protects network and transport layers without requiring network layer authentication information. It can be deployed without pre- deployment of authentication material for IPsec or pre-shared information, and protects all transport layer protocols using a single mechanism. BTNS raises the level of effort for many types of network or transport layer attacks. 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 open 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 protected without requiring pre-deployed authentication credentials. We anticipate that it will use the extant, ephemeral Diffie-Hellman exchange employed in IKE to establish pairwise secret keys between ends of an association, effectively removing the authentication responsibility from IKE. 4.6. Vulnerabilities The vulnerabilities presented by BTNS depend on which variant is supported at each end of an association. Hosts connecting to BTNS hosts are vulnerable to communicating with a masquerader throughout the association for SAB, or until higher layers provide additional authentication for CBB. As a result, authentication data (e.g., passwords) sent to a masquerading peer could be disclosed to an attacker. This is a deliberate design tradeoff; in BTNS, network and transport layer access is no longer gated by the identity presented by 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 provide access control for local resources. Traffic selectors of the BTNS SPD entries 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 Touch, Black, Wang Expires December 5, 2006 [Page 14] Internet-Draft BTNS Problem and Applicability June 2006 provide the missing authentication. CCB also relies on the effectiveness of the binding of higher layer authentication to the BTNS network association. 4.7. Summary of Uses, Vulnerabilities, and Benefits The following is a summary of the properties of each type of BTNS based on the previous subsections: SAB CBB ------------------------------------------------------------- Uses Open services iSCSI [14], Kerberos [11] Peer-to-peer Zero-config. infrastructure Vuln. Masqueraders Masqueraders until bound Needs data rate limit Needs conn. rate limit Load on IPsec Load on IPsec Exposure to open access Benefit Protects L3 & L4 Protects L3 & L4 Avoids all auth. keys Avoids L3 auth keys Full auth. once bound These issues were largely noted in previous sections; some of the more generic issues, such as the increased load on IPsec processing, are addressed in the Security Considerations section of this document. 5. Security Considerations This section presents the threat models for BTNS, and discusses other security issues based on the threat models for different modes of BTNS. Some of the issues were mentioned previously in the document, but are listed again for completeness. 5.1. Threat Models and Evaluation BTNS is intended to protect sessions from a variety of threats, including on-path, man-in-the-middle attacks 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" authentication during session establishment, but does not protect session establishment itself. Touch, Black, Wang Expires December 5, 2006 [Page 15] Internet-Draft BTNS Problem and Applicability June 2006 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. Furthermore, Stand-alone BTNS is not intended to protect the endpoint from nodes masquerading as legitimate clients. Channel-Bound BTNS can protect from such masquerading, though at a later point after the security association is established. BTNS is also not intended to protect from DoS attacks that seek to overload a CPU performing authentication and other security computations, nor is it intended to protect from configuration mistakes. These final assumptions are the same as that of the IP network protocol security suite. Finally, manual keying is not considered in because it is unsafe for protocols that exchange large amounts of traffic such as IP Storage (e.g., RFC-3723 forbids use of manual keying with the IP Storage protocols) [1]. The following sections discuss the implications of the threat models in more details. 5.2. Interaction with Other Extant Security As with any aspect of network security, the use of BTNS must not interfere with extant security services. Within an IPsec context, the scope of BTNS must be limited to the SPD and PAD entries that explicitly specify BTNS, and to the resulting SAD entries. It is incumbent on system administrators to deploy BTNS only where safe, preferably as a substitute to the use of "bypass" which exempts specified traffic from IPsec cryptograph protection. In other words, BTNS should be used only as a substitute for no security, rather than as a substitute for stronger security. This is particularly relevant for the use of BTNS for BGP. Full authentication is preferred for BGP. When that is not available, other methods, such as IP address filtering, can help reduce the vulnerability of SAB to exposure to anonymous access. 5.3. MITM and Masquerader Attacks Previous sections have described how CBB can counter MITM and masquerader attacks, even though BTNS does not protect key exchange nor does it authenticate peer identities at the network layer. Nonetheless, there are some security issues regarding CBB that must be carefully evaluated before deploying BTNS. For regular IPsec/IKE, 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 Touch, Black, Wang Expires December 5, 2006 [Page 16] Internet-Draft BTNS Problem and Applicability June 2006 failure. On the other hand, a man-in-the-middle attack on IPsec with CBB is discovered later than if IKE authentication were used. With CBB, the BTNS-IKE step will succeed because it is unauthenticated, and the security association will be set up. The man in the middle will not be discovered until the higher layer authentication fails. There are two security concerns with this approach: possible exposure of sensitive authentication information to the attackers, and resource consumption before attacks are detected. The exposure of information depends on the higher layer authentication protocols used in applications. If the higher layer authentication requires exchange of sensitive information (e.g., password-derived materials) that can be attacked offline, the attackers can gain such information even though they will be detected. Therefore, CBB must not be used with higher layer protocols that may expose sensitive information during authentication exchange. For example, Kerberos V AP exchanges would leak little other than the target's krb5 principal name, while Kerberos V AS exchanges using PA- ENC-TIMESTAMP pre-authentication would leak material that can then be attacked offline. The latter should not be used with BTNS, even with Channel Binding. 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. The resource consumption issue is addressed in the next section on DoS attacks. 5.4. DoS Attacks and Resource Consumptions BTNS deployment means that more traffic will require cryptographic operations, which increase the load on those receiving protected traffic and/or verifying incoming traffic. The additional computation raises vulnerability to overloading, which can be the result of legitimate flash crowds or from zombies utilized in DoS attacks. Although this may itself present a substantial impediment to deployment, it is a challenge to all cryptographically protected communication systems, and BTNS does not create or amplify that aspect per se. This document does not address the impact BTNS has on such load. The effects of the increased resource consumption are twofold. It raises the level of effort for attackers such as MITM, but it also consumes more resources to detect such attacks or to reject spoofed traffic. At the network layer, proper limits or access controls for resources should be setup for all BTNS sessions. CBB sessions can be granted with better access once the higher layer authentications Touch, Black, Wang Expires December 5, 2006 [Page 17] Internet-Draft BTNS Problem and Applicability June 2006 succeed. The same principles apply to the higher layer protocols in the CBB sessions. Special care must be taken to avoid undue resource usage before the authentication is established in the applications. 5.5. Exposure to Anonymous Access The use of SAB necessarily implies that a service is being offered for open access, since network layer authentication information is not available. SAB must not be used with services that are not intended to be openly available. 5.6. ICMP Attacks This document does not consider ICMP attacks because the use of BTNS- IPsec does not change the existing guideline [9] on how ICMP traffic is handled. BTNS-IPsec focuses on authentication part of establishing security associations. It does not alter the IPsec traffic processing model and protection boundary. As a result, the entire IPsec packet processing guidelines, including ICMP processing, remain the same for BTNS-IPsec. 5.7. Leap of Faith and Cached Credentials BTNS allows systems to accept and establish security associations with peers without authenticating their identities. This resembles the notion of "Leap of Faith" utilized in other security protocols and applications such as SSH [21] and SSL [3]. In both SSH and SSL, implementations are allowed to accept peer credentials (e.g., public keys or other authentication information) without authentication, and the applications are further allowed to store these unauthenticated credentials in local databases for future references. Similar to BTNS, such measures are allowed due to the lack of 'widely deployed key infrastructure' [21] and to improve ease of use and end-user acceptance. There are still subtle differences. Both SSH and SSL require proper warnings and options in the applications to reject unauthenticated credentials, while BTNS will accept those automatically if they match the corresponding policy entries. Once a credential is accepted for the first time, it can be cached in both SSH and SSL, and can be used automatically without further warnings. This latter behavior matches that of BTNS, but with different implications. SSH and SSL can use these cached, unauthenticated credentials to verify future sessions with the same peers. On the other hand, the key issue with BTNS-IPsec is whether these cached credentials should be treated differently in terms of trust levels. For SAB without Channel Binding, the cached credentials should not be treated differently because they remain Touch, Black, Wang Expires December 5, 2006 [Page 18] Internet-Draft BTNS Problem and Applicability June 2006 unauthenticated, while CBB may consider granting better access for cached credentials with previous higher layer authentications. Note that these should not be considered as formal recommendations because BTNS as presently described does not consider inter-session caching of credentials. It is left to future work to address the specifics of cached credentials. 5.8. Configuration Errors BTNS does not address errors of configuration that could result in increased vulnerability; such vulnerability is already possible using "bypass". This work presumes that associations using BTNS will consist of SPD entries, just as "bypass," therefore separated from associations with more conventional, stronger security. 6. Other Issues and Related Efforts This section discusses other issues not included in any previous categories, and lists the related work. 6.1. NAT Traversal The issues regarding NAT traversal are mostly orthogonal to BTNS because BTNS focuses on relaxing peer authentication in IKE and IPsec policy. BTNS with Channel Binding may cause problems with NAT if the IDs are tied to addresses at the application layer. Note that this problem is not specific to BTNS, but rather to the design of generic IPsec Channel Binding APIs. Therefore, this document does not consider the impact of NAT or NAPT on the capabilities it intends to provide, except as are already addressed by the current IPsec specifications. 6.2. Mobility and Multihoming BTNS does not consider the impact of mobility or multihoming on the capabilities it intends to provide. 6.3. Related 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, e.g., to assist in deploying signed certificates and CA information [7]. The IETF KINK WG is focused on adapting Kerberos for IKE, Touch, Black, Wang Expires December 5, 2006 [Page 19] Internet-Draft BTNS Problem and Applicability June 2006 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 automatic discovery of hosts willing to do a BTNS- like encryption, with authentication being exchanged by leveraging existing use of the DNS [13]. BTNS differs from all three in that BTNS is intended to avoid the need for such infrastructure altogether, rather than to automate it. 7. IANA Considerations There are no IANA issues in this document. This section should be removed by the RFC-Editor prior to final publication. 8. Acknowledgments This document was inspired by discussions on the IETF TCPM WG about the recent spoofed RST attacks on BGP routers and various solutions, as well as discussions in the nfsv4 and ips WGs about how to better integrate with IPsec. The concept of BTNS was the result of these discussions as well as with USC/ISI's T. Faber, A. Falk, and B. Tung, and discussions on the IETF SAAG WG and IPsec mailing list. The authors would like to thank the members of those WGs and lists, as well as the IETF BTNS BOFs and WG and its associated ANONsec mailing list (http://www.postel.org/anonsec) for their feedback, in particular, Steve Kent, Sam Hartman, Nicolas Williams, and Pekka Savola. 9. References 9.1. Normative References (none) 9.2. Informative References [1] Aboba, B., J. Tseng, J. Walker, V. Rangan, and F. Travostino, "Securing Block Storage Protocols over IP," RFC-3723, April 2004. [2] CERT Vulnerability Note VU#415294, "The Border Gateway Protocol relies on persistent TCP sessions without specifying authentication requirements," 4/20/2004. Touch, Black, Wang Expires December 5, 2006 [Page 20] Internet-Draft BTNS Problem and Applicability June 2006 [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] Kaufman, C., (ed.), "Internet Key Exchange (IKEv2) Protocol," RFC-4306, Dec. 2005. [9] Kent, S., R. Atkinson, "Security Architecture for the Internet Protocol," RFC-2401, Nov. 1998. [10] Kent, S., K. Seo, "Security Architecture for the Internet Protocol," RFC-4301, Dec. 2005. [11] Kohl, J., C. Neuman, "The Kerberos Network Authentication Service (V5)," RFC-1510, Sep. 1993. [12] Mostkowitz, R., P. Nikander, P. Jokela (ed.), T. Henderson, "Host Identity Protocol," (work in progress), draft-ietf-hip-base-05, Mar. 2006. [13] Richardson, M., Redelmeier, D., "Opportunistic Encryption using The Internet Key Exchange (IKE)," RFC-4322, Dec. 2005. [14] Satran, J., K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC-3720, April 2004. [15] 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. [16] Steward, R., Dalal, M., "Improving TCP's Robustness to Blind In-Window Attacks," (work in progress), draft-ietf-tcpm-tcpsecure-04, Feb. 2006. Touch, Black, Wang Expires December 5, 2006 [Page 21] Internet-Draft BTNS Problem and Applicability June 2006 [17] Stewart, R., et al., "Stream Control Transmission Protocol," RFC-2960, Oct. 2000. [18] TCP SYN-cookies, http://cr.yp.to/syncookies.html [19] Touch, J., "Defending TCP Against Spoofing Attacks," (work in progress), draft-ietf-tcpm-tcp-antispoof-04.txt, May. 2006. [20] Williams, N., "On the Use of Channel Bindings to Secure Channels," (expired, was work in progress), draft-ietf-nfsv4-channel-bindings-03, Feb. 2005. [21] Ylonen, T, Lonvick, C. (ed.), "The Secure Shell (SSH) Protocol Architecture," RFC-4251, Jan. 2006. 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 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 Touch, Black, Wang Expires December 5, 2006 [Page 22] Internet-Draft BTNS Problem and Applicability June 2006 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 (2006). 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 December 5, 2006 [Page 23] Internet-Draft BTNS Problem and Applicability June 2006 Touch, Black, Wang Expires December 5, 2006 [Page 24]