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)
draft-ietf-btns-prob-and-applic-01.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 March 23, 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,
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
Abstract..........................................................1
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
Acknowledgment...................................................21
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
keys.
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
prohibitive.
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
stack.
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
description:
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
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
layers
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
service.
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
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.
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
Peer-to-peer
Zero-config. infrastructure
Vuln. Masqueraders Masqueraders until bound
Needs data rate limit Needs conn. rate limit
Load on IPsec Load on IPsec
Exposure to open access
Benefit Protects L3 & L4 Protects L3 & L4
Avoids all auth. keys Avoids L3 auth keys
Full auth. once bound
These issues were largely noted in previous sections; some of the
more generic issues, such as the increased load on IPsec processing,
are addressed in the Security Considerations section of this
document.
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
suite.
PKI4IPsec is an IETF WG focused on providing an automatic
infrastructure for the configuration of Internet security services,
e.g., to assist in deploying signed certificates and CA information
[7]. The IETF KINK WG is focused on adapting Kerberos for IKE,
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
associations.
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
altogether.
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
publication.
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
(none)
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-
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] 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
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.
Phone: +1 (310) 448-9151
Email: touch@isi.edu
David Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
USA
Phone: +1 (508) 293-7953
Email: black_david@emc.com
Yu-Shun Wang
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.
Phone: +1 (310) 448-8742
Email: yushunwa@isi.edu
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
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).
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 March 23, 2006 [Page 21]
