[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: March 2006                                  September 23, 2005

                    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 March 23, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.


   The Internet network security protocol suite, IPsec, consisting of
   IKE, ESP, and AH, currently requires authentication via IKE of
   network layer entities to bootstrap security. This authentication can
   be based on mechanisms such as pre-shared symmetric keys,
   certificates and associated asymmetric keys, or the use of Kerberos.

Touch, Wang, Black      Expires March 23, 2006                 [Page 1]

Internet-Draft      BTNS Problem and Applicability       September 2005

   The need for authentication information and its associated identities
   between network layer entities can be a significant obstacle to
   deploying network security.  This document explains the rationale for
   extending the Internet network security suite to enable use of IPsec
   security mechanisms without full IKE authentication. These extensions
   are intended to protect communication "better than nothing" (BTNS) on
   their own (Stand Alone BTNS, or SAB), and may be useful in providing
   network layer security that can be authenticated by higher layers in
   the protocol stack, called Channel Bound BTNS (CBB). This document
   also explains situations in which use of SAB and CBB extensions are
   appropriate and can achieve their intended benefit.

Table of Contents

   1. Introduction...................................................3
      1.1. Assumptions...............................................4
   2. Problem Statement..............................................5
      2.1. Transport Protection From Packet Spoofing.................5
      2.2. Authentication at Multiple Layers.........................6
      2.3. Example - Secure Socket Layer.............................8
      2.4. Threat Models.............................................8
   3. Applicability Statement........................................9
      3.1. Uses.....................................................10
         3.1.1. Symmetric SAB.......................................11
         3.1.2. Asymmetric SAB......................................12
         3.1.3. Symmetric CBB.......................................12
         3.1.4. Asymmetric CBB......................................13
      3.2. Vulnerabilities..........................................13
      3.3. Benefits.................................................14
      3.4. Summary of Uses, Vulnerabilities, and Benefits...........14
   4. Related Work and Other Issues.................................15
      4.1. Not Considered...........................................15
      4.2. Other IETF Efforts.......................................15
      4.3. Extensions and Other Issues..............................15
   5. Security Considerations.......................................16
      5.1. Evaluation of Threat Models..............................17
      5.2. Protections..............................................18
   6. IANA Considerations...........................................18
   7. Acknowledgments...............................................18
   8. References....................................................18
      8.1. Normative References.....................................18
      8.2. Informative References...................................18
   Author's Addresses...............................................20
   Intellectual Property Statement..................................20
   Disclaimer of Validity...........................................21
   Copyright Statement..............................................21

Touch, Black, Wang      Expires March 23, 2006                 [Page 2]

Internet-Draft      BTNS Problem and Applicability       September 2005


1. Introduction

   Internet security is provided by a variety of protocols at different
   layers of the protocol stack. Security at the network layer, IP, is
   critical to protecting both network and transport protocols. The
   current Internet network security suite, IPsec, uses IKE, which
   currently relies on pre-shared or pre-deployed information to
   authenticate identity [4][8][9]. This pre-shared/pre-deployed state
   is a significant impediment to its widespread use.

   This document describes a number of practical problems caused by the
   dependency of the Internet security suite on pre-shared or pre-
   deployed information for authentication, and describes "better than
   nothing security" (BTNS), an extension of the Internet security suite
   that secures communication between two parties. BTNS allows IPsec
   security configured by IKE in which one or both parties avoid the
   need to be authenticated either by a shared private key, certificate
   signed by a mutually-known certification authority, or other, pre-
   deployed authentication infrastructure (e.g., Kerberos) [6][10].

   Consider the case of transport protocols. Increases in network
   performance and the use of long-lived connections have resulted in
   increased vulnerability of connection-oriented transport protocols to
   attacks. Such attacks can be resisted to some extent within the
   transport layer by performing additional validity checks, requiring
   additional mechanisms added to each transport protocol. More direct
   security can be provided, either at the transport or network layer.
   This security currently requires a predetermined way to authenticate
   the endpoints with a pre-shared secret, a public key infrastructure
   (PKI) with shared trusted anchors, or an external key coordination
   system such as Kerberos. In all cases, secure communication can be
   established only after endpoints mutually assert authenticated
   identities as specified in their access control policies.

   Also consider the case where upper layers provide authentication. Web
   transactions are secured by TLS and SSL, where the server has a
   certificate authenticated by a well-known certification authority
   (i.e., whose public keys are predeployed on most browsers) [3][12].
   Clients typically lack such certificates, as they are prohibitively
   expensive either in price or effort to obtain. Current secure web
   transactions authenticate the client via application information,
   such as passwords or credit card information. Web transaction
   security protects the application information, but does not protect
   the transport layer, where connections can be interrupted by spoofed
   traffic. The network layer cannot use the IPsec suite to authenticate

Touch, Black, Wang      Expires March 23, 2006                 [Page 3]

Internet-Draft      BTNS Problem and Applicability       September 2005

   clients because clients often lack authentication credentials for
   IKE, even though authentication is available at upper layers.

   This document suggests the need for an alternate approach to security
   that does not require authentication at the network layer. The goal
   of this approach to security is to protect established connections
   but not to protect connection establishment, while also avoiding the
   need to deploy network layer secrets, keys, and/or identities in
   advance. In this case, BTNS allows cryptographic protection for the
   network and transport layers without requiring the endpoints to be
   authenticated at the network layer. It is possible to couple network
   layer security to higher layer protocols where strong authentication
   is supported or to provide at least some protection at the network
   layer even when no additional support is available at higher layers.
   The resulting protection is not as complete, but it would be "better
   than nothing security", thus the name BTNS.

   This document presents the overall goal that BTNS is intended to
   address: the desire to deploy security which avoids the need for pre-
   deployed authentication identities and associated secrets or keys at
   the network layer to achieve network layer protection which is
   "better than nothing." It also discusses the intended application of
   BTNS solutions, including Stand-Alone BTNS (SAB), as well as
   integration with authentication at higher layers of the protocol
   stack that still protect network and transport layer traffic, called
   Channel Bound BTNS (CBB).

1.1. Assumptions

   This problem and applicability statement for BTNS assumes the use of
   the IP network security protocol suite, i.e., IPsec, consisting of
   IKE, ESP, and AH, as a reasonable platform for these extensions
   because they are widely available, comparatively modular, and are
   currently experiencing deployment challenges due to their dependence
   on pre-deployed authentication hierarchy and associated secrets or

   This document considers two variants of BTNS: one which supports
   network protection without relying on authentication credentials and
   associated secrets or keys (stand-alone), and one which can be
   coupled with authentication higher in the protocol stack (channel-
   bound). The differences in the problem statement and applicability of
   both variants are addressed.

   This document does not address what components of the IP network
   security protocol suite may need modification or configuration to

Touch, Black, Wang      Expires March 23, 2006                 [Page 4]

Internet-Draft      BTNS Problem and Applicability       September 2005

   support BTNS. Example scenarios are provided as design motivations
   and are not intended to be a comprehensive list.

2. Problem Statement

   BTNS removes the need for conventional authentication in providing
   network security. There are two primary motivations for doing so: to
   remove the need to deploy authentication information altogether
   (which this document defines later as Stand Alone BTNS, or SAB), and
   to remove the need for redundant authentication at multiple layers
   (which this document defines later as Channel Bound BTNS, or CBB).
   The first is further motivated by the prevalence of proposed
   modifications to transport layer protocols to provide protections
   similar to a secure network layer.

2.1. Transport Protection From Packet Spoofing

   TCP, like many other protocols, has been susceptible to off-path
   third-party attacks [18]. Such attacks rely on the increase of
   commodity platforms supporting open access to previously privileged
   resources, such as raw sockets or privileged ports. Given such
   access, it is trivial for anyone to generate a packet with any header
   desired. This, coupled with the lack of sufficient ingress filtering
   to drop such spoofed traffic, has resulted in an increase in off-path
   third-party spoofing attacks. Such 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 done at the transport layer as described below.

   Some of these modifications augment the transport protocol with 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][17]. 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) [11][16].

   Such modifications are, at best, temporary patches to the ubiquitous
   vulnerability to spoofing attacks. The obvious solution to spoofing
   is to validate the segments of a connection, either at the transport
   layer (which the patch provides, weakly) or the network layer. The
   IPsec suite already intends to provide authentication of a network
   layer packet and its contents, but its deployment overhead can be

Touch, Black, Wang      Expires March 23, 2006                 [Page 5]

Internet-Draft      BTNS Problem and Applicability       September 2005

   Protecting the network from spoofed packets is ultimately an issue of
   authentication, ensuring that a receiver's interpretation of the
   source of a packet is accurate. Authentication validates the identity
   of the source of the packet. The current IPsec suite assumes that
   identity is validated either by a trusted third party - e.g., the
   certification authority - or by a pre-deployed shared secret. Such an
   identity is unique and invariant across associations (pairwise
   security configuration), and can be used to reject packets that are
   not authentic.

   There is weaker notion of identity, one which is bootstrapped from
   the session association itself. The identity doesn't mean "Bill
   Smith" or "owner of shared secret X2YQ", but means something more
   like "the entity with whom 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 for that association.

   BTNS thus provides a kind of intra-association integrity, a kind of
   authentication where the identity is not authenticated across
   separate associations or out-of-band, but does not change during the
   association. This kind of BTNS is 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].
   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, depending on them to support
   authentication as well. The reality is that few routers are
   configured to support authentication, and the result is the use of
   unsecured BGP. 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. 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 at the

Touch, Black, Wang      Expires March 23, 2006                 [Page 6]

Internet-Draft      BTNS Problem and Applicability       September 2005

   higher layer protocol using a higher layer identity and secret or
   key. End-node software is then responsible for making sure that the
   identities used for these two authentications are consistent in some
   fashion, an authorization policy decision.  In principle a single
   authentication should suffice, removing the need for:

   o  the second authentication

   o  configuration and management of the identities and secrets or keys
      for the second authentication

   o  determining in some fashion that the two authentications are
      consistent (and potential vulnerabilities if this is not done)

   IPsec is not always present for these higher layer protocols, and
   even when present, will not always be used.  Hence, if there is a
   choice, the higher layer protocol authentication is preferable as it
   will always be available for use independent of IPsec.

   A "better than nothing" security approach to IPsec can address this
   problem by setting up IPsec without an authentication and then
   extending the higher layer authentication to check that the two ends
   of the higher layer protocol session are on two ends of the same
   security association. This check is referred in this document as
   "channel binding", thus the name Channel Bound BTNS (CBB) [19].
   Channel binding must be done in a fashion that prevents a man-in-the-
   middle from changing the security association identity when it is
   checked and from causing two different security associations to have
   the same identity.  Adding the security association identifier to
   authentication mechanisms based on one-way hashes, key exchanges, or
   (public key) cryptographic signatures are three means by which
   channel binding can be accomplished with man-in-the-middle
   resistance.  This requires that the security association identifier
   be the same at both ends of the security association [19].

   In order to perform channel binding there must be a channel to bind
   to; IPsec defines no such channels, though such channels can be
   constructed by transports layered above IP through cooperation
   between the transports 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 the transports are also needed for communicating
   channel binding data to applications, and may be needed as well as
   for applications to construct their own IPsec channels over
   connection-less, datagram-oriented transports.

Touch, Black, Wang      Expires March 23, 2006                 [Page 7]

Internet-Draft      BTNS Problem and Applicability       September 2005

2.3. Example - Secure Socket Layer

   Secure web transactions are a good example of an ubiquitous Internet
   security mechanism that provide application-layer security for web
   client/server communication. They consist of HTTP over SSL/TLS,
   which, like IKE, relies on X.509 certificates and associated
   certification authorities (CAs) to identify parties [3][12]. SSL/TLS
   can be used where one or both parties use certificates that are not
   authenticated by CAs preshared by those parties. The session may
   remain unauthenticated, or may be further authenticated at the
   application layer.

   Consider the case of an individual accessing a corporate website to
   purchase a product. Communication to the website is encrypted, based
   on certificates on both the corporate and individual sides. The
   corporate certificate is typically signed by a well-known CA, whose
   public key is predeployed with most web browsers, to authenticate the
   identity of the website. The individual's certificate is only self-
   signed, to avoid the expense of registering with a CA.

   The corporate website agrees to communicate with the individual's web
   browser even though the individual's identity has not yet been
   established. In some cases, the individual's identity is later
   verified at the application layer by confirming mutually shared
   information (mother's maiden name, an account number), or by using a
   protected preshared secret (password, PIN, etc.). In some cases, the
   individual's identity is never confirmed.

   Regardless of whether identity is confirmed later (by analogue, as in
   CBB) or not at all (by analogue, as in SAB), the communication is
   secured despite the lack of authentication. The protection is
   persistent within a connection, but not necessarily between
   connections - which is why passwords are used to access protected
   sites even for those that have been visited recently. Such systems
   are widely deployed asymmetrically for the web, and symmetrically for
   e-mail. The kind of protection afforded by these examples of SSL is
   the inspiration for BTNS. BTNS differs from SSL in that it protects
   the network and transport layer, whereas SSL protects the application
   layer. BTNS can thus protect TCP connections from spoofed packets
   that are low-effort attacks that interfere with the connection
   itself, which SSL cannot.

2.4. Threat Models

   The following is a brief summary of the threat models of BTNS. A more
   detailed assessment is provided in the Security Considerations
   section of this document.

Touch, Black, Wang      Expires March 23, 2006                 [Page 8]

Internet-Draft      BTNS Problem and Applicability       September 2005

   BTNS is intended to protect sessions from a variety of threats,
   including man-in-the-middle after key exchange, other on-path attacks
   after key exchange, and off-path attacks. It is intended to protect
   the contents of a session once established using a "leap of faith"
   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. Stand-alone BTNS is further not
   intended to protect the endpoint from nodes masquerading as
   legitimate clients but rather to raise the level of effort of an
   attack to that of emulating a client. BTNS together with
   authentication from higher layers in the stack can protect from such
   masquerading, depending on how the authentication is coupled with the
   BTNS associations, and at a later point in the protocol exchange.

   BTNS is also not intended to protect from DOS overload of the CPU
   load of verification, nor is it intended to protect from user
   misconfiguration. These final assumptions are the same as that of the
   IP network protocol security suite. Finally, manual keying is not
   considered in this document.

3. Applicability Statement

   BTNS is intended to provide network and transport protection in the
   absence of network layer authentication. As a result, the security
   services offered by BTNS are a subset of those of the original IPsec
   security suite: connectionless integrity, protection against replays
   (a form of partial sequence integrity), confidentiality (encryption),
   data origin authentication, and limited traffic flow confidentiality.
   Access control policies will need to be extended to allow "leap of
   faith authentication" for the identities involved, thus reducing the
   network layer assurance that one is communicating with a specific
   identified counterpart.

   BTNS protects associations once established, but does not itself
   limit with whom associations are made. It is generally appropriate
   for services open to the public but for which protected associations
   are desired, or for services that can be authenticated at higher
   layers in the protocol stack.

   BTNS reduces vulnerability to attacks after associations have been
   established by parties not participating in the association. This
   helps protect systems from low-effort attacks on sessions or
   connections involving higher levels of resources.

Touch, Black, Wang      Expires March 23, 2006                 [Page 9]

Internet-Draft      BTNS Problem and Applicability       September 2005

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

3.1. Uses

   BTNS is intended for use for open services (SAB) or for private
   services that can be authenticated by higher layer protocols (CBB).
   It can also be used either symmetrically, where both parties lack
   network layer authentication information, or asymmetrically, where
   only one party is lacking. There are a number of cases to consider,
   based on the matrix of the security endpoint capabilities of SAB,
   CBB, and conventional authentication (denoted as IKE below).

                 |    IKE    |    SAB    |    CBB    |
                 |           |           |           |
             IKE |    IKE    |   A-SAB   |  AI-CBB   |
                 |           |           |           |
                 |           |           |           |
             SAB |   A-SAB   |   S-SAB   |  AS-CBB   |
                 |           |           |           |
                 |           |           |           |
             CBB |  AI-CBB   |  AS-CBB   |   S-CBB   |
                 |           |           |           |

   The above table shows the kind of authentication possible based on
   the capabilities of the two security endpoints, with the following

   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

Touch, Black, Wang      Expires March 23, 2006                [Page 10]

Internet-Draft      BTNS Problem and Applicability       September 2005

   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

   The following is a discussion of each of these use cases.
   Vulnerabilities and benefits are discussed in later subsections of
   this section separately. The labels in the table are organized by the
   least authenticated side, where SAB is the least secure because it
   uses no authentication, CBB is more secure because it uses
   authentication external to IPsec, and IKE is the most secure because
   it relies on integrated authentication. Note that the measure of
   least/most secure is based solely on the integration of
   authentication in these labels, and does not consider the comparative
   strength of various authentication algorithms.

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

   Peer-to-peer networks could utilize S-SAB because no peer needs to be
   privileged and preregistered at any layer in the stack. S-SAB
   protects all transport protocols between two peers; this is
   convenient because peer nets may test a variety of transport
   protocols in order to traverse NATs and firewalls.

   Open services, such as web servers, may also use S-SAB when their
   identities need not be authenticated to clients, but where the
   communication would benefit from protection. Such servers might
   provide large files either not validated or validated by other means
   (e.g., published MD5 hashes). These large downloads present a target
   for off-path attacks, which could be mitigated by the use of S-SAB.

Touch, Black, Wang      Expires March 23, 2006                [Page 11]

Internet-Draft      BTNS Problem and Applicability       September 2005

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

3.1.2. Asymmetric SAB

   Asymmetric SAB (A-SAB) allows one party lacking network layer
   authentication information to establish associations with another
   which possesses authentication, the latter by any means supported by
   existing IKE.

   Asymmetric SAB is useful for protecting the transport connections for
   open services on the Internet, e.g., commercial web servers, DNS,
   etc. In these cases, the server is typically authenticated by a
   widely known CA, as is done with SSL at the application layer, but
   the clients need not be authenticated.

   A-SAB also secures transport for streaming media as would be used to
   view broadcast streaming such as webcasts for remote education and

3.1.3. Symmetric CBB

   Symmetric CCB (S-CCB) allows hosts lacking network layer
   authentication information to utilize authentication at higher layers
   in the protocol stack.

   Similar authentication already occurs at the application layer in
   TLS/SSL during secure web transactions to sites whose certificates
   are self-signed or signed by untrusted CAs when external user
   validation is used. Web clients ask "do you want to trust this
   certificate for this session." In this way, the user is the upper
   layer authentication and the user's channel is bound to the
   application layer inside the application itself. When such upper
   layer verification is not used, TLS/SSL with self-signed or untrusted
   CAs behaves more like S-SAB or A-SAB.

   S-CCB could utilize application layer authentication, including
   challenge/response PINs, such as used by S/Key in software or copy
   protection dongles, or login passwords.

Touch, Black, Wang      Expires March 23, 2006                [Page 12]

Internet-Draft      BTNS Problem and Applicability       September 2005

3.1.4. Asymmetric CBB

   Asymmetric CBB (A-CBB) allows one host lacking network layer
   authentication information to later authenticate itself using higher
   layers in the protocol stack. A-CBB has variants depending on whether
   the other side is authenticated at the network layer using
   conventional IKE-supported means (AI-CBB) or protected but not
   authenticated using SAB (AS-CBB). In AI-CBB, one side uses channel
   bound BTNS and the other uses IKE; in AS-CBB one side uses channel
   bound BTNS and the other uses stand-alone BTNS.

   Most of the A-CBB variants are useful for securing remote access with
   unidirectional passwords, such as for FTP and email, to avoid sending
   cleartext passwords prior to login, but where application security is
   not available - e.g., for legacy applications. Which variant is
   appropriate depends on the sensitivity of the passwords; most would
   tend to be used with S-CBB or AI-CBB, where the server is
   authenticated before the client presents the password.

   AS-CBB is useful for obtaining authenticated data from a public
   source, where client identity is irrelevant but server identity is.

3.2. Vulnerabilities

   The vulnerabilities presented by BTNS depend on which variant is
   supported on the two ends of an association. Hosts connecting to BTNS
   hosts are vulnerable to communicating to a masquerader throughout the
   association for SAB, or until higher layers provide additional
   authentication for CBB. This is a deliberate design tradeoff; in
   BTNS, network and transport layer access is no longer gated by the
   network identity of the other host, so this opens hosts to
   masquerading and flash crowd attacks. Conversely, BTNS secures
   connections to hosts that cannot authenticate at the network layer,
   so the network and transport layers are more protected.

   Lacking network layer authentication information, other means must be
   used to protect local resources. Filters can be used to limit which
   interfaces, address ranges, and port ranges can access BTNS-enabled
   services. Rate limiting can further restrict resource usage. For SAB,
   these protections need to be considered throughout associations,
   whereas for CBB they need be present only until higher layer
   protocols provide the missing authentication. CCB also relies on the
   effectiveness of the binding of higher layer authentication to the
   BTNS network association.

Touch, Black, Wang      Expires March 23, 2006                [Page 13]

Internet-Draft      BTNS Problem and Applicability       September 2005

3.3. Benefits

   BTNS protects network and transport layers without requiring network
   layer authentication information. It can be deployed without
   configuration or pre-shared information, and protects the entire
   variety of transport protocols using a single mechanism.

   BTNS raises the level of effort for a network or transport attack.
   Casual, simple packet attacks need to be augmented to full
   associations and connection establishment for SAB, so that an
   attacker must perform as much work as regular host. SAB thus raises
   the effort for a DDOS attack to that of emulating a flash crowd. For
   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 predeployed authentication. We anticipate that it will use
   the original Diffie-Hellman exchange to establish pairwise private
   keys between ends of an association, effectively omitting the
   authentication phase currently used in IKE.

3.4. 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               Password/PIN services
              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

Touch, Black, Wang      Expires March 23, 2006                [Page 14]

Internet-Draft      BTNS Problem and Applicability       September 2005

4. Related Work and Other Issues

4.1. Not Considered

   BTNS does not (at this time) consider the impact of mobility or
   multihoming on the capabilities it intends to provide.

   BTNS does not consider the impact of NAT or NAPT on the capabilities
   it intends to provide, except as are already addressed by the current
   Internet network security suite.

4.2. Other IETF Efforts

   There are a number of related efforts in the IETF and elsewhere to
   reduce the configuration effort of deploying the Internet security

   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)
   is a system for automating authentication infrastructure by
   leveraging the 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.

   Finally, BTNS does not address a number of existing challenges to
   using the Internet network security suite. DOS attacks that involve
   overloading endpoints with invalid signatures are not addressed, as
   they are a natural aspect of using security and BTNS does not create
   or amplify that aspect per se, except to possibly encourage broader
   use of security. BTNS does not address errors of configuration that
   could result in increased vulnerability; such vulnerability is
   already possible using "bypass". We presume that associations using
   BTNS will be separated from associations with more conventional,
   stronger security just as "bypass" is currently separated from those

4.3. Extensions and Other Issues

   One extension of particular interest is the ability to retain
   association "identity" across multiple associations, i.e., to be able
   to know when a host is communicating with a host it has had a

Touch, Black, Wang      Expires March 23, 2006                [Page 15]

Internet-Draft      BTNS Problem and Applicability       September 2005

   previous BTNS association with. Such capabilities are already used in
   SSL applications, e.g., for web clients and email access.

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:

   1. avoiding interference with conventional network layer security
      including, but not limited to, IPsec

   2. increased load on IPsec to reject spoofed traffic

   3. integration with higher-layer authentication (for CBB)

   4. exposure to anonymous access (for SAB)

   As with any aspect of network security, the use of BTNS must not
   interfere with conventional security services. It must be possible to
   limit BTNS to specific interfaces, addresses, protocols, and/or ports
   much the same way it is already possible to skip network security
   based on these parameters. It is incumbent on the system
   administrators to deploy BTNS only where safe, preferably as a
   substitute to the use of "bypass" which avoids network security

   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, in which case
   authentication is preferred, but when 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 use cryptographic
   transforms. Receivers will observe increased processing load in
   verifying incoming traffic as a result. Although this may itself
   present a substantial impediment to deployment, it is a challenge to
   all cryptographically protected communication systems. The use of
   crypto increases the load on those verifying it; we do not consider
   the impact that BTNS has on such load simply by encouraging the use
   of security.

   Where BTNS is integrated with higher layer authentication, i.e., CBB,
   special care must be taken to avoid undue resource use before higher
   layer authentication is established. Further, the ways in which BTNS
   is integrated with the higher layer protocol must take into

Touch, Black, Wang      Expires March 23, 2006                [Page 16]

Internet-Draft      BTNS Problem and Applicability       September 2005

   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 deployed on services
   that are not intended to be openly available.

5.1. Evaluation of Threat Models

   BTNS is intended to protect the network and transport layer between
   two parties after an association is established. SAB is not intended
   to control to whom associations are established based on
   authenticated identity. CBB does not control with whom associations
   are established initially, but allows higher layer protocols that
   provide authentication to couple to network layer security after the
   association is established, at which time the association can be
   adjusted accordingly.

   BTNS does not protect from man-in-the-middle attacks during key
   exchange during association establishment.

   SAB in particular is intended for use for open services or services
   for which other filtering can reduce exposure, and CBB may also be
   used in that capacity. In those cases, neither protects from overload
   due to flash crowds or DDOS attacks posing as flash crowds.

   BTNS does not address attacks to the association establishment key
   exchange, which can be substantial for flash crowds of open services
   of SAB or for CBB until higher layer authentication is established.

   BTNS does not address the increased load on the system that the use
   of IPsec security services will incur, either for processing
   legitimate traffic or for rejecting attack traffic.

   When channel binding is used with BTNS, a man-in-the-middle attack on
   IPsec is discovered later than if IKE authentication were used.  A
   man in the middle cannot subvert IKE authentication, and hence an
   attempt to attack it via use of two separate security associations
   will cause an IKE authentication failure.  In contrast, with BTNS and
   channel binding, the BTNS-IKE step will succeed (because it would be
   unauthenticated), and the security association will be set up, only
   to have the higher layer authentication fail after more resources
   have been invested in this session.  Nonetheless, this is an
   improvement over the alternative of minimizing the configuration of
   IPsec by using a group pre-shared key, which provides no defense
   against man-in-the-middle attacks among the nodes sharing the key.

Touch, Black, Wang      Expires March 23, 2006                [Page 17]

Internet-Draft      BTNS Problem and Applicability       September 2005

5.2. Protections

   BTNS does protect from man-in-the-middle attacks after the initial
   association is established.  Man-in-the-middle during association
   establishment for CBB can be detected via channel binding with higher
   layer authentication.

   BTNS protects the network and transport layer from on-path non-man-
   in-the-middle (i.e., snooping) and from off-path attacks. This helps
   especially protect transport connections from attack.

6. IANA Considerations

   There are no IANA issues in this document.

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

7. Acknowledgments

   This document was inspired by discussions on the IETF TCPM WG about
   the recent spoofed RST attacks on BGP routers and various solutions.
   The concept of BTNS was the result of discussions on that list as
   well as with USC/ISI's T. Faber, A. Falk, and B. Tung, as well as
   members of 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.

8. References

8.1. Normative References


8.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]   Dalal, M., (ed.), "Improving TCP's Robustness to Blind In-
         Window Attacks," (work in progress), draft-ietf-tcpm-tcpsecure-
         03.txt, May 2005.

Touch, Black, Wang      Expires March 23, 2006                [Page 18]

Internet-Draft      BTNS Problem and Applicability       September 2005

   [3]   Frier, A., P. Karlton, P. Kocher, "The SSL 3.0 Protocol",
         Netscape Communications Corp., Nov 18, 1996.

   [4]   Harkins, D., D. Carrel, "The Internet Key Exchange (IKE)," RFC-
         2409, Nov. 1998.

   [5]   Heffernan, A., "Protection of BGP Sessions via the TCP MD5
         Signature Option," RFC-2385, Aug. 1998.

   [6]   IETF KINK WG web pages, http://www.ietf.org/html.charters/kink-

   [7]   IETF PKI4IPSEC WG web pages,

   [8]   Kent, S., R. Atkinson, "Security Architecture for the Internet
         Protocol," RFC-2401, Nov. 1998.

   [9]   Kent, S., K. Seo, "Security Architecture for the Internet
         Protocol," (work in progress), draft-ietf-ipsec-rfc2401bis-06,
         Mar. 2005.

   [10]  Kohl, J., C. Neuman, "The Kerberos Network Authentication
         Service (V5)," RFC-1510, Sep. 1993.

   [11]  Mostkowitz, R., P. Nikander, P. Jokela (ed.), T. Henderson,
         "Host Identity Protocol," draft-ietf-hip-base-03, June 2005.

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

   [13]  Richardson, M., "Opportunistic Encryption using The Internet
         Key Exchange (IKE)," (work in progress), draft-richardson-
         ipsec-opportunistic-17.txt, Jan. 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]  Stewart, R., et al., "Stream Control Transmission Protocol,"
         RFC-2960, Oct. 2000.

   [17]  TCP SYN-cookies, http://cr.yp.to/syncookies.html

Touch, Black, Wang      Expires March 23, 2006                [Page 19]

Internet-Draft      BTNS Problem and Applicability       September 2005

   [18]  Touch, J., "Defending TCP Against Spoofing Attacks," (work in
         progress), draft-ietf-tcpm-tcp-antispoof-01.txt, Apr. 2005.

   [19]  Williams, N., "On the Use of Channel Bindings to Secure
         Channels," (work in progress), draft-ietf-nfsv4-channel-
         bindings-03.txt, 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

   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

Touch, Black, Wang      Expires March 23, 2006                [Page 20]

Internet-Draft      BTNS Problem and Applicability       September 2005

   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 (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.


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

Touch, Black, Wang      Expires March 23, 2006                [Page 21]

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