[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5387

BTNS WG                                     J. Touch, D. Black, Y. Wang
Internet Draft                                          USC/ISI and EMC
Expires: August 2006                                  February 17, 2006

                    Problem and Applicability Statement
                  for Better Than Nothing Security (BTNS)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 17, 2006.


   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 August 17, 2006                 [Page 1]

Internet-Draft      BTNS Problem and Applicability        February 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............................4
         2.1.2. Authentication Methods...............................5
         2.1.3. Current IPsec Limits on Unauthenticated Peers........5
      2.2. Upper Layer...............................................5
         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...........................................12
      4.3. Symmetric CBB............................................13
      4.4. Asymmetric CBB...........................................13
      4.5. Vulnerabilities..........................................14
      4.6. Benefits.................................................14
      4.7. Summary of Uses, Vulnerabilities, and Benefits...........15
   5. Security Considerations.......................................15
      5.1. Threat Models and Evaluation.............................16
   6. Related Efforts and Other Issues..............................17
      6.1. Issues Not Addressed.....................................17
      6.2. Related IETF Efforts.....................................17
      6.3. Extensions...............................................18
   7. IANA Considerations...........................................18
   8. Acknowledgments...............................................18
   9. References....................................................19
      9.1. Normative References.....................................19
      9.2. Informative References...................................19
   Author's Addresses...............................................20
   Intellectual Property Statement..................................21
   Disclaimer of Validity...........................................21
   Copyright Statement..............................................21

Touch, Black, Wang     Expires August 17, 2006                 [Page 2]

Internet-Draft      BTNS Problem and Applicability        February 2006

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

   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.

Touch, Black, Wang     Expires August 17, 2006                 [Page 3]

Internet-Draft      BTNS Problem and Applicability        February 2006

   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.

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.

Touch, Black, Wang     Expires August 17, 2006                 [Page 4]

Internet-Draft      BTNS Problem and Applicability        February 2006

   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

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.

Touch, Black, Wang     Expires August 17, 2006                 [Page 5]

Internet-Draft      BTNS Problem and Applicability        February 2006

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 [1]. 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)
   [2][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.

   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.

Touch, Black, Wang     Expires August 17, 2006                 [Page 6]

Internet-Draft      BTNS Problem and Applicability        February 2006

   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

   With regard to BGP in particular, it has been understood that the use
   of appropriate authentication is the preferred solution [1] 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 [15][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 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:

   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.

Touch, Black, Wang     Expires August 17, 2006                 [Page 7]

Internet-Draft      BTNS Problem and Applicability        February 2006

   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

   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
   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

Touch, Black, Wang     Expires August 17, 2006                 [Page 8]

Internet-Draft      BTNS Problem and Applicability        February 2006

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 core 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.

   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

Touch, Black, Wang     Expires August 17, 2006                 [Page 9]

Internet-Draft      BTNS Problem and Applicability        February 2006

   suite. The notes address only the differences when applied to BTNS-

   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 August 17, 2006                [Page 10]

Internet-Draft      BTNS Problem and Applicability        February 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

   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

      (*) 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

   The following is a discussion of the applicability of each of the
   combinations in the above table. In general, BTNS protects
   associations once established, but does not limit with which

Touch, Black, Wang     Expires August 17, 2006                [Page 11]

Internet-Draft      BTNS Problem and Applicability        February 2006

   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 after associations have been established
   to attacks from 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 recommended primarily for open services, it
   can provide some level of protection for private services when the
   alternative is no protection at all (as in the case of BGP, e.g.).

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

4.2. Asymmetric SAB

   Asymmetric SAB (A-SAB) allows one party lacking network layer
   authentication information to establish associations with another

Touch, Black, Wang     Expires August 17, 2006                [Page 12]

Internet-Draft      BTNS Problem and Applicability        February 2006

   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

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

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
   applicability of this and other CBB modes will be discussed in detail
   in a future channel bindings document.

Touch, Black, Wang     Expires August 17, 2006                [Page 13]

Internet-Draft      BTNS Problem and Applicability        February 2006

4.5. 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
   provide the missing authentication. CCB also relies on the
   effectiveness of the binding of higher layer authentication to the
   BTNS network association.

4.6. 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.

Touch, Black, Wang     Expires August 17, 2006                [Page 14]

Internet-Draft      BTNS Problem and Applicability        February 2006

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, Kerberos
              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

5. Security Considerations

   Although security considerations are discussed throughout this
   document, there are several issues to be addressed regarding when and
   where to use BTNS:

   o  avoiding interference with other extant network layer security
      including, but not limited to, IPsec

   o  increased load on IPsec to reject spoofed traffic

   o  integration with higher-layer authentication (for CBB)

   o  exposure to anonymous access (for SAB)

   As with any aspect of network security, the use of BTNS must not
   interfere with extant security services. It must be possible to limit
   BTNS to specific SPD 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.

Touch, Black, Wang     Expires August 17, 2006                [Page 15]

Internet-Draft      BTNS Problem and Applicability        February 2006

   In summary, 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.

   The use of BTNS means that more traffic will require cryptographic
   operations. Receivers will observe increased processing load in
   decrypting and/or 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 receiving protected
   traffic; this document does not address the impact BTNS has on such

   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 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.1. Threat Models and Evaluation

   The following is a brief summary of the threat models of BTNS. 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.

   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.

Touch, Black, Wang     Expires August 17, 2006                [Page 16]

Internet-Draft      BTNS Problem and Applicability        February 2006

   A man-in-the-middle attack on IPsec with CBB 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.  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 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.

   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., [RFC3723] forbids use of
   manual keying with the IP Storage protocols).

6. Related Efforts and Other Issues

6.1. Issues Not Addressed

   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.

6.2. 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

   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,
   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)

Touch, Black, Wang     Expires August 17, 2006                [Page 17]

Internet-Draft      BTNS Problem and Applicability        February 2006

   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[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 security-related computation 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 consist of SPD entries, just as
   "bypass," therefore separated from associations with more
   conventional, stronger security.

6.3. Extensions

   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 with which it has
   had a previous BTNS association. Such capabilities are already used
   in SSH and SSL/TLS applications.

7. IANA Considerations

   There are no IANA issues in this document.

   This section should be removed by the RFC-Editor prior to final

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 and Sam Hartman.

Touch, Black, Wang     Expires August 17, 2006                [Page 18]

Internet-Draft      BTNS Problem and Applicability        February 2006

9. References

9.1. Normative References


9.2. Informative References

   [1]   CERT Vulnerability Note VU#415294, "The Border Gateway Protocol
         relies on persistent TCP sessions without specifying
         authentication requirements," 4/20/2004.

   [2]   Steward, R., Dalal, M., "Improving TCP's Robustness to Blind
         In-Window Attacks," (work in progress),
         draft-ietf-tcpm-tcpsecure-04, Feb. 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,

   [7]   IETF PKI4IPSEC WG web pages,

   [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-04, Oct. 2005.

Touch, Black, Wang     Expires August 17, 2006                [Page 19]

Internet-Draft      BTNS Problem and Applicability        February 2006

   [13]  Rescorla, E., "HTTP Over TLS," RFC-2818, May 2000.

   [14]  Richardson, M., "Opportunistic Encryption using The Internet
         Key Exchange (IKE)," (expired, was work in progress),
         draft-richardson-ipsec-opportunistic-17, Jan. 2005.

   [15]  Satran, J., K. Meth, C. Sapuntzakis, M. Chadalapaka, E.
         Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
         RFC-3720, April 2004.

   [16]  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.

   [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-03.txt, Feb. 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.

Author's Addresses

   Joe Touch
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   Phone: +1 (310) 448-9151
   Email: touch@isi.edu

   David Black
   EMC Corporation
   176 South Street
   Hopkinton, MA 01748

   Phone: +1 (508) 293-7953
   Email: black_david@emc.com

Touch, Black, Wang     Expires August 17, 2006                [Page 20]

Internet-Draft      BTNS Problem and Applicability        February 2006

   Yu-Shun Wang
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).

Touch, Black, Wang     Expires August 17, 2006                [Page 21]

Internet-Draft      BTNS Problem and Applicability        February 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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Touch, Black, Wang     Expires August 17, 2006                [Page 22]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/