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]