BTNS WG                                     J. Touch, D. Black, Y. Wang
Internet Draft                                          USC/ISI and EMC
Expires: January 2006                                      July 1, 2005



                    Problem and Applicability Statement
                  for Better Than Nothing Security (BTNS)
                  draft-ietf-btns-prob-and-applic-00.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 1, 2006.

Copyright Notice

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

Abstract

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



Touch, Wang, Black     Expires January 1, 2006                 [Page 1]


Internet-Draft      BTNS Problem and Applicability            July 2005


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

Table of Contents


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


Touch, Black, Wang     Expires January 1, 2006                 [Page 2]


Internet-Draft      BTNS Problem and Applicability            July 2005



1. Introduction

   Internet security is provided by a variety of protocols at different
   layers of the protocol stack. Security at the network layer, IP, is
   critical to protecting both network and transport protocols, the
   latter because most include network identifiers in their
   pseudoheaders, e.g., in TCP and UDP [2][12]. The current Internet
   network security suite, IPsec, uses IKE, which currently relies on
   pre-shared or pre-deployed information to authenticate identity
   [3][6][9]. This pre-shared/pre-deployed state is a significant
   impediment to its ubiquitous use.

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

   Consider the case of transport protocols. Increases in network
   performance and the use of long-lived connections have resulted in
   increased vulnerability of connection-oriented transport protocols to
   attack. Such attacks can be resisted to some extent within the
   transport layer by performing additional validity checks, requiring
   additional mechanisms added to each transport protocol. More direct
   security can be provided, either at the transport or network layer.
   This security currently requires a predetermined way to authenticate
   the endpoints, e.g., a pre-shared secret, a certificate hierarchy
   with pre-shared public keys, or an external key coordination system
   such as Kerberos. In all cases, security can be established only
   after ensuring that the endpoints are definitively identified before
   their traffic is trusted.

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


Touch, Black, Wang     Expires January 1, 2006                 [Page 3]


Internet-Draft      BTNS Problem and Applicability            July 2005


   traffic. The network layer lacks authentication and thus cannot use
   the IPsec suite, even though authentication is available at upper
   layers.

   This document suggests the need for an alternate approach to security
   that avoids the need for authentication at the network layer. The
   purpose is to protect a connection only after it has been
   established. In this case, BTNS allows cryptographic protection for
   the network and transport layers without requiring the endpoints to
   be strongly authenticated at the network layer, possibly coupling
   network layer security to higher layer protocols where strong
   authentication is supported.

   The goal of this approach to security is to protect established
   connections but not to protect connection establishment, while
   avoiding the need to deploy network layer secrets, keys, and/or
   identities in advance. The resulting protection is not as complete,
   but it would be "better than nothing security", thus the name BTNS.

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

1.1. Assumptions

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

   This document considers two variants of BTNS: one which supports
   network protection without relying on mutual pre-deployed shared
   authentication identities and associated secrets or keys, and one
   which can be coupled with authentication higher in the protocol
   stack. The differences in the problem statement and applicability of
   both variants are addressed.




Touch, Black, Wang     Expires January 1, 2006                 [Page 4]


Internet-Draft      BTNS Problem and Applicability            July 2005


   This document does not address what components of the IP network
   security protocol suite may need modification or configuration to
   support BTNS. Example scenarios are provided as design motivations
   and are not intended to be a comprehensive list.

2. Problem Statement

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

2.1. Transport Protection From Packet Spoofing

   TCP, like many other protocols, has been susceptible to off-path
   third-party attacks [14]. Such attacks rely on the increase of
   commodity platforms supporting public access to previously privileged
   resources, such as root-level access. Given such access, it is
   trivial for anyone to generate a packet with any header desired.
   This, coupled with the lack of sufficient ingress filtering to drop
   such spoofed traffic, has resulted in an increase in off-path third-
   party spoofing attacks. As a result, a number of proposed solutions
   have been developed, some of which modify TCP processing to defeat
   off-path third-party spoofs by performing additional, security checks
   inside the transport layer.

   Some of these modifications augment the transport protocol with its
   own security, e.g., TCP/MD5 [2]. Others modify the core TCP
   processing rules to make it harder for off-path attackers to inject
   meaningful packets, either during the initial handshake (e.g.
   SYNcookies) or after a connection is established (e.g., TCPsecure)
   [2][14]. Some of these modifications are new to TCP, but have already
   been incorporated into other transport protocols (e.g., SCTP) or
   intermediate (so-called L3.5) protocols (e.g., HIP) [10][14].

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



Touch, Black, Wang     Expires January 1, 2006                 [Page 5]


Internet-Draft      BTNS Problem and Applicability            July 2005


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

   There is weaker notion of identity, one which is bootstrapped from
   the session association itself. The identity doesn't mean "Bill
   Smith" or "owner of shared secret X2YQ", but means something more
   like "the end with whom I have been talking on connection #23". Such
   identity is not invariant across associations, but because it is
   invariant within an association it can still be used to provide
   protection for that association.

   BTNS thus provides a kind of intra-association integrity, a kind of
   relative authentication, where the identity is not authenticated
   across separate associations or out-of-band, but does not change
   during the association. This kind of BTNS is known as Stand Alone
   BTNS (SAB), because the protection is afforded solely by the use of
   BTNS extensions, without authentication from higher layers in the
   protocol stack.

2.2. Authentication at Multiple Layers

   Some protocols used on the Internet provide authentication at a layer
   above the transport, but rely on the IPsec suite for packet-by-packet
   cryptographic integrity and confidentiality services.  Examples of
   such protocols include iSCSI and a proposed security mode for NFSv4
   security <need better explanation> [16].  With the current IPsec
   suite, the result is two authentications; one at the IPsec layer,
   using an identity for IKE and an associated secret or key, and once
   at the higher layer protocol using a higher layer identity and secret
   or key.  End-node software is then responsible for making sure that
   the identities used for these two authentications are consistent in
   some fashion, an authorization policy decision.  In principle a
   single authentication should suffice, removing the need for:

   o  the second authentication

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




Touch, Black, Wang     Expires January 1, 2006                 [Page 6]


Internet-Draft      BTNS Problem and Applicability            July 2005


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

   IPsec is not always present for these higher layer protocols, and
   even when present, will not always be used.  Hence, if there is a
   choice, the higher layer protocol authentication is preferable as it
   will always be available for use independent of IPsec.  This is
   complicated by the fact that IPsec must set up its security
   association before the higher layer protocol can send any traffic.

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

2.3. Example - Secure Socket Layer

   HTTPS is a good example of an ubiquitous Internet security mechanism,
   providing application-layer security for web client/server
   communication. It consists of HTTP over SSL/TLS, which, like IKE,
   relies on X.509 certificates and associated certificate authorities
   (CAs) to identify parties [3][14]. In contrast to IKE, SSL can be
   used where one or both parties use certificates which are not
   authenticated by CAs preshared by those parties. Security may remain
   unauthenticated, or may be further authenticated at the application
   layer.

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



Touch, Black, Wang     Expires January 1, 2006                 [Page 7]


Internet-Draft      BTNS Problem and Applicability            July 2005


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

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

2.4. Threat Models

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

   BTNS is intended to protect sessions from a variety of threats,
   including man-in-the-middle after key exchange, other on-path attacks
   after key exchange, and off-path attacks. It is intended to protect
   the contents of a session once established using a "leap of faith"
   during session establishment, but does not protect session
   establishment itself.

   BTNS is not intended to protect the key exchange itself, so this
   presents an opportunity for a man-in-the-middle attack or a well-
   timed attack from other sources. Stand-alone BTNS is not intended to
   protect the endpoint from nodes masquerading as legitimate clients
   but rather to raise the level of effort of an attack to that of
   emulating a client. BTNS together with authentication from higher
   layers in the stack can protect from such masquerading, depending on
   how the authentication is coupled with the BTNS associations, and at
   a later point in the protocol exchange.

   BTNS is also not intended to protect from DOS overload of the CPU
   load of verification, nor is it intended to protect from user
   misconfiguration. These final assumptions are the same as that of the


Touch, Black, Wang     Expires January 1, 2006                 [Page 8]


Internet-Draft      BTNS Problem and Applicability            July 2005


   IP network protocol security suite. Finally, manual keying is not
   considered in this document.

3. Applicability Statement

   BTNS is intended to provide network and transport protection in the
   absence of network layer authentication, whether alone (stand-alone)
   or in conjunction with application authentication. Recall that the
   former is called Stand Alone BTNS (SAB), and the latter Channel Bound
   BTNS (CBB).

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

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

   BTNS increases vulnerability to overloading, which can be the result
   of legitimate flash crowds or from zombies posing as clients.
   Although BTNS should be used only for public services, it can provide
   some level of protection for private services if the alternative is
   no protection at all.

3.1. Uses

   BTNS is intended for use for public services (SAB) or for private
   services that can be authenticated by higher layer protocols (CBB).
   It can also be used either symmetrically, where both parties lack
   network layer authentication information, or asymmetrically, where
   only one party is lacking. There a number of cases to consider, based
   on the matrix of SAB, CBB, and conventional authentication (denoted
   as IKE below); note that these are classified by the weaker side of
   the authentication, where SAB is the weakest, CBB is less weak, and
   IKE is the strongest:










Touch, Black, Wang     Expires January 1, 2006                 [Page 9]


Internet-Draft      BTNS Problem and Applicability            July 2005


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


   1. IKE: both sides possess conventional, IKE-supported authentication

   2. Symmetric SAB (S-SAB): both sides lack network layer
      authentication information (and lack or do not use higher layer
      authentication)

   3. Asymmetric SAB (A-SAB): one side lacks network layer
      authentication information (and lacks or does not use higher layer
      authentication), but the other possesses it

   4. Symmetric CBB (S-CBB): both sides lack network layer
      authentication information, and both possess authentication at a
      higher layer in the protocol stack

   5. Asymmetric CBB (A-CBB): one side lacks network layer
      authentication information and possesses authentication at a
      higher layer in the protocol stack; there are two variants,
      Asymmetric IKE CBB(AI-CBB) where the other side possesses
      conventional IKE-supported authentication, and asymmetric stand-
      alone CBB (AS-CBB), where the other side lacks network layer
      authentication information and lacks authentication at higher
      layers

   The following is a discussion of each of these use cases.
   Vulnerabilities and benefits are discussed in later subsections of
   this section separately.

3.1.1. Symmetric SAB

   Symmetric SAB (S-SAB) assumes that both parties lack network layer
   authentication information and that authentication is not available


Touch, Black, Wang     Expires January 1, 2006                [Page 10]


Internet-Draft      BTNS Problem and Applicability            July 2005


   from higher layer protocols. S-SAB can still protect network and
   transport protocols, but does not provide authentication at all. It
   is useful where large files or long connections would benefit from
   not being interrupted by DOS attacks, but where the particular
   endpoint identities are not important.

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

   Public services, such as web servers, may also use S-SAB when their
   identity need not be authenticated to clients, but where the
   communication would benefit from protection. Such servers might
   provide large files, either unvalidated or validated by other means
   (e.g., published MD5 hashes). Downloads of these large files present
   a target for off-path attacks, which could be reduced by the use of
   S-SAB. S-SAB may also be useful for protecting the transport of
   voice-over-IP (VoIP) between peers, such as direct calls between VoIP
   clients.

3.1.2. Asymmetric SAB

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

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

   A-SAB also secures transport for streaming media as would be used
   between a VoIP client and the commercial VoIP provider, or to view
   broadcast streaming such as webcasts for remote education and
   entertainment.

3.1.3. Symmetric CBB

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




Touch, Black, Wang     Expires January 1, 2006                [Page 11]


Internet-Draft      BTNS Problem and Applicability            July 2005


   Such authentication already occurs during web transactions to sites
   whose certificates are self-signed or signed by untrusted CAs; web
   clients ask "do you want to trust this certificate for this session,"
   e.g. S-CCB could support challenge/response PINs, such as used by
   S/Key in software or copy protection dongles.

3.1.4. Asymmetric CBB

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

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

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

3.2. Vulnerabilities

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

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


Touch, Black, Wang     Expires January 1, 2006                [Page 12]


Internet-Draft      BTNS Problem and Applicability            July 2005


   effectiveness of the binding of higher layer authentication to the
   BTNS network association.

3.3. Benefits

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

   BTNS raises the level of effort for a network or transport attack.
   Casual, simple packet attacks need to be augmented to full
   associations and connection establishment for SAB, so that an
   attacker must perform as much work as regular host. SAB thus raises
   the effort for a DDOS attack to that of emulating a flash crowd. For
   public services, there may be no way to distinguish such a DDOS
   attack from a legitimate flash crowd anyway.

   BTNS also allows individual associations to be private without
   requiring predeployed authentication. We anticipate that it will use
   the original Diffie-Hellman exchange to establish pairwise private
   keys between ends of an association, effectively omitting the
   authentication phase currently used in IKE. As such, associations
   will be private, as well as protected.

4. Security Considerations

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

   1. avoiding interference with conventional network layer
      authentication

   2. increased load on IPsec to reject spoofed traffic

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

   4. exposure to anonymous access (for SAB)

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


Touch, Black, Wang     Expires January 1, 2006                [Page 13]


Internet-Draft      BTNS Problem and Applicability            July 2005


   altogether. In summary, BTNS should be used only as a substitute for
   no security, rather than as a substitute for stronger security.

   The use of BTNS means that more traffic will use cryptographic
   transforms. Receivers will observe increased processing load in
   verifying incoming traffic as a result. Although this may itself
   present a substantial impediment to deployment, it is a challenge to
   all cryptographically protected communication systems. The use of
   crypto increases the load on those verifying it; we do not consider
   the impact that BTNS has on such load simply by encouraging the use
   of security.

   Where BTNS is integrated with higher layer authentication, i.e., CBB,
   special care must be taken to avoid undue resource use before higher
   layer authentication is established. Further, the ways in which BTNS
   is integrated with the higher layer protocol must take into
   consideration vulnerabilities that could be introduced in the APIs
   between these two systems or in the information that they share.

   Finally, the use of SAB necessary implies that a service is being
   offered for public access, since network layer authentication
   information is not available. SAB must not be deployed on services
   that are not intended to be publicly available.

4.1. Evaluation of Threat Models

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

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

   SAB in particular is intended for use for publicly available
   services, and CBB may also be used in that capacity. In those cases,
   neither protects from overload due to flash crowds or DDOS attacks
   posing as flash crowds.

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


Touch, Black, Wang     Expires January 1, 2006                [Page 14]


Internet-Draft      BTNS Problem and Applicability            July 2005


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

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

4.2. Protections

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

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

5. Related Work and Other Issues

5.1. Not Considered

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

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

5.2. Other IETF Efforts

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

   PKI4IPsec is an IETF WG focused on providing an automatic
   infrastructure for the configuration of Internet security services,


Touch, Black, Wang     Expires January 1, 2006                [Page 15]


Internet-Draft      BTNS Problem and Applicability            July 2005


   e.g., to assist in deploying signed certificates and CA information
   [6]. The IETF KINK WG is focused on adapting Kerberos for IKE,
   enabling IKE to utilize the Kerberos key distribution infrastructure
   rather than requiring certificates signed by CAs or shared private
   keys [6]. KINK takes advantage of an existing architecture for
   automatic key management in Kerberos. Opportunistic Encryption (OE)
   is a system for automating authentication infrastructure by
   leveraging the existing use of the DNS [14]. BTNS differs from all
   three in that BTNS is intended to avoid the need for such
   infrastructure altogether, rather than to automate it.

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

5.3. Extensions and Other Issues

   One extension of particular interest is the ability to retain
   association "identity" across multiple associations, i.e., to be able
   to know when a host is communicating with a host it has had a
   previous BTNS association with. Such capabilities are already used in
   SSL applications, e.g., for web clients and email access.

   <any other issues?>

6. Acknowledgments

   <placeholder>

7. References

7.1. Normative References

   (none)

7.2. Informative References

   [1]   Arends, R., R. Austein, M. Larson, D. Massey, S. Rose, "DNS
         Security Introduction and Requirements," RFC-4033, Mar. 2005.


Touch, Black, Wang     Expires January 1, 2006                [Page 16]


Internet-Draft      BTNS Problem and Applicability            July 2005


   [2]   Dalal, M., (ed.), "Improving TCP's Robustness to Blind In-
         Window Attacks," (work in progress), draft-ietf-tcpm-tcpsecure-
         03.txt, May 2005.

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

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

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

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

   [7]   IETF PKI4IPSEC WG web pages,
         http://www.ietf.org/html.charters/pki4ipsec-charter.html

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

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

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

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

   [12]  Postel, J., "User Datagram Protocol," RFC-768 / STD-6, Aug.
         1980.

   [13]  Postel, J., (ed.), "Transmission Control Protocol," RFC-793 /
         STD-7, Sept. 1981.

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

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

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


Touch, Black, Wang     Expires January 1, 2006                [Page 17]


Internet-Draft      BTNS Problem and Applicability            July 2005


   [17]  Shepler, S., B. Callaghan, D. Robinson, R. Thurlow, C., Beame,
         M. Eisler, D. Noveck, "Network File System (NFS) version 4
         Protocol," RFC-3530, April, 2003.

   [18]  Stewart, R., et al., "Stream Control Transmission Protocol,"
         RFC-2960, Oct. 2000.

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

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

   [21]  Williams, N., "On the Use of Channel Bindings to Secure
         Channels," (work in progress), draft-ietf-nfsv4-channel-
         bindings-03.txt, Feb. 2005.

   [22]  Copy protection dongles <insert good ref here>

   [23]  S/Key <insert good ref here>

Author's Addresses

   Joe Touch
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   U.S.A.

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


   David Black
   EMC Corporation
   176 South Street
   Hopkinton, MA 01748
   USA

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









Touch, Black, Wang     Expires January 1, 2006                [Page 18]


Internet-Draft      BTNS Problem and Applicability            July 2005


   Yu-Shun Wang
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   U.S.A.

   Phone: +1 (310) 448-8742
   Email: yushunwa@isi.edu


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).


Touch, Black, Wang     Expires January 1, 2006                [Page 19]


Internet-Draft      BTNS Problem and Applicability            July 2005


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

Acknowledgment

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









































Touch, Black, Wang     Expires January 1, 2006                [Page 20]