BTNS WG J. Touch, D. Black, Y. Wang
Internet Draft USC/ISI and EMC
Intended status: Informational February 13, 2007
Expires: August 2007
Problem and Applicability Statement
for Better Than Nothing Security (BTNS)
draft-ietf-btns-prob-and-applic-05.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 August 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Internet network security protocol suite, IPsec, consisting of
IKE, ESP, and AH, generally requires authentication of network layer
entities to bootstrap security. This authentication can be based on
mechanisms such as pre-shared symmetric keys, certificates and
Touch, Wang, Black Expires August 13, 2007 [Page 1]
Internet-Draft BTNS Problem and Applicability February 2007
associated asymmetric keys, or the use of Kerberos. The need to
deploy authentication information and its associated identities to
network layer entities can be a significant obstacle to use of
network security. This document explains the rationale for extending
the Internet network security suite to enable use of IPsec security
mechanisms without authentication. These extensions are intended to
protect communication in a "better than nothing" (BTNS) fashion. The
extensions may be used on their own (Stand Alone BTNS, or SAB), or
may be useful in providing network layer security that can be
authenticated by higher layers in the protocol stack, called Channel
Bound BTNS (CBB). This document also explains situations in which use
of SAB and CBB extensions are appropriate.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 Error!
Reference source not found..
Table of Contents
1. Introduction...................................................3
2. Problem Statement..............................................5
2.1. Network Layer.............................................5
2.1.1. Authentication Identities............................5
2.1.2. Authentication Methods...............................5
2.1.3. Current IPsec Limits on Unauthenticated Peers........6
2.2. Upper Layer...............................................6
2.2.1. Transport Protection from Packet Spoofing............6
2.2.2. Authentication at Multiple Layers....................8
3. BTNS-IPsec Overview and Threat Models..........................9
3.1. BTNS-IPsec Overview.......................................9
3.2. BTNS-IPsec Security Services.............................10
3.3. BTNS-IPsec Modes.........................................11
4. Applicability Statement.......................................12
4.1. Benefits.................................................13
4.2. Vulnerabilities..........................................13
4.3. Stand-Alone BTNS (SAB)...................................14
4.3.1. Symmetric SAB.......................................14
4.3.2. Asymmetric SAB......................................14
4.4. Channel-Bound BTNS (CBB).................................15
4.5. Summary of Uses, Vulnerabilities, and Benefits...........16
Touch, Wang, Black Expires August 13, 2007 [Page 2]
Internet-Draft BTNS Problem and Applicability February 2007
5. Security Considerations.......................................16
5.1. Threat Models and Evaluation.............................16
5.2. Interaction with Other Extant Security...................17
5.3. MITM and Masquerader Attacks.............................17
5.4. DoS Attacks and Resource Consumptions....................18
5.5. Exposure to Anonymous Access.............................19
5.6. ICMP Attacks.............................................19
5.7. Leap of Faith............................................19
5.8. Connection Hijacking through Rekeying....................20
5.9. Configuration Errors.....................................21
6. Other Issues and Related Efforts..............................21
6.1. NAT Traversal............................................21
6.2. Mobility and Multihoming.................................22
6.3. Related IETF Efforts.....................................22
7. IANA Considerations...........................................22
8. Acknowledgments...............................................22
9. References....................................................23
9.1. Normative References.....................................23
9.2. Informative References...................................23
Author's Addresses...............................................25
Intellectual Property Statement..................................25
Disclaimer of Validity...........................................26
1. Introduction
Network security is provided by a variety of protocols at different
layers in the stack. At the network layer, the IPsec protocol suite
is used to secure IP traffic. IPsec and Internet Key Exchange
protocol (IKE) present an all-or-nothing alternative by providing
protection from a wide array of possible threats, but requiring
authentication [4][8][9][10]. In turn authentication requires
deployment of network-level authentication credentials, and this can
be an obstacle to IPsec usage. This document discusses the issues
with regard to this dependency, and introduces "Better Than Nothing
Security" (BTNS) as one solution. It also describes various modes of
BTNS, and explores the characteristics of applications that will
benefit from using each mode. The remainder of this section provides
an overview of the background and problem scenario.
The process of establishing secure network communications consists of
two functions: policy and mechanism. The policy function determines
"who" gets which types of security services, and the mechanism
function applies the selected services to the corresponding
communication traffic. The requirement for authentication credentials
stems from the need to verify the "who;" i.e., to authenticate the
identities of the communicating peers.
Touch, Wang, Black Expires August 13, 2007 [Page 3]
Internet-Draft BTNS Problem and Applicability February 2007
There are two basic approaches to authentication: using pre-deployed
information, or employing out-of-band communications. Out-of-band
authentication can be done through a trusted third party, a separate
channel to the peer, or the same channel but at a higher layer. It
requires mechanisms and interfaces to bind the authenticated
identities to the secure channels, and is out-of-scope for this
document (although it may be possible to extend the channel binding
mode of BTNS to work with such mechanisms). Pre-deployed information
includes pre-shared secrets and credentials authenticated by trusted
authorities. This form of authentication often requires manual
deployment and coordination among communicating peers. Furthermore,
authenticated credentials such as certificates signed by
certification authorities (CA) can be cumbersome and expensive to
obtain.
These factors increase the impact of IKE's requirement for successful
authentication based on pre-deployed information before security
services are offered. Consequently, users and applications often do
not use IPsec to protect the network layer, but rely solely on higher
layer security protocols or no security at all. As the problem
statement section will describe, higher layer security protocols may
not be enough to protect against some network layer spoofing attacks.
To improve the situation, one could either reduce the hurdles to
obtain and configure authentication information, or remove
authentication at the network layer. The latter is the core idea of
BTNS, which provides anonymous (unauthenticated) keying for IPsec to
create Security Associations (SAs) with peers who do not possess
valid authentication credentials. This requires extensions to the
IPsec architecture and possibly extensions or profiles of IKE. As the
new BTNS modes in IPsec relax the authentication requirement, the
impacts, tradeoffs, and risks must be thoroughly understood before
applying BTNS to any communications. More specifically, this document
will address the issues on whether and when network layer
authentication can be removed, the risks of using BTNS, and finally,
the impacts to the existing IPsec architecture.
The next section discusses the issues that IKE's strict requirements
for network layer authentication cause for IPsec. Section 3 provides
a high level overview of BTNS-IPsec, including the security services
offered. Section 4 explores the applicability of BTNS-IPsec, followed
by a discussion of the risks and other security considerations in
Section 5. Section 6 lists other related efforts.
Touch, Wang, Black Expires August 13, 2007 [Page 4]
Internet-Draft BTNS Problem and Applicability February 2007
2. Problem Statement
This section describes the problems that motivated the development of
BTNS. The primary concern is that IPsec is not widely utilized
despite rigorous development effort and emphasis on network security
by users and organizations. There are also debates on which layer is
best for securing network communications, and how security protocols
at different layers should interact. The following discussion roughly
categorizes these issues by layers: network layer and higher layers.
2.1. Network Layer
At the network layer, one of the hurdles is to satisfy the
authentication requirements of IPsec and IKE. This section
investigates the problems on network layer authentication and the
result of this requirement.
2.1.1. Authentication Identities
Current IPsec authentication supports several types of identities in
the Peer Authorization Database (PAD): IPv4 addresses, IPv6
addresses, DNS names, Distinguished Names, RFC 822 email addresses,
and Key IDs [10]. All require either CA-signed certificates or pre-
shared secrets to authenticate. These can be roughly categorized into
network layer identifiers and other identifiers.
The first three, IPv4/IPv6 addresses and DNS names are network layer
identifiers. The main issue with IP addresses is that they are no
longer stable identifiers representing the same physical systems
consistently due to dynamic address assignments (DHCP) and increases
in system mobility. DNS names are affected because the name to
address mapping is not always up to date as a result.
There are two main drawbacks with other, non-network-layer
identifiers. It is too restrictive because there are likely other
forms of identifiers not covered by the PAD specification. It could
also result in multiple authentications on the same identifiers at
different layers. In addition, the list of identifiers is not
complete; some higher layer protocols use additional types of
identifiers that are not supported by IPsec. These issues are also
related to channel binding and will be further discussed later.
2.1.2. Authentication Methods
As described earlier, CA-signed certificates and pre-shared secrets
are the only methods of authentications accepted by current IPsec and
IKE specifications. Pre-shared secrets require manual configuration
Touch, Wang, Black Expires August 13, 2007 [Page 5]
Internet-Draft BTNS Problem and Applicability February 2007
and out-of-band communications. The verification process of CA-signed
certificates is cumbersome and there may be a monetary cost in
obtaining the certificates. The combination of these factors is one
likely reason why IPsec is not widely used except in environments
with the highest security requirements.
2.1.3. Current IPsec Limits on Unauthenticated Peers
Pre-configuration only works if the peer identities are known in
advance. The lack of unauthenticated IPsec modes prevents secure
communications at the network layer with unauthenticated or unknown
peers, even when they are subsequently authenticated in a higher
layer protocol or application. The lack of a channel binding API
between IPsec and upper layer protocols further forces such
communications to completely bypass IPsec, leaving network layer
unprotected.
2.2. Upper Layer
For upper layers, the following discussion first focuses on whether
IPsec is necessary if transport layer security is already in use.
This would further motivate the need to reduce the hurdle of using
IPsec. Another issue is regarding authentication at both IPsec and
higher layer protocols for the same connection.
2.2.1. Transport Protection from Packet Spoofing
Consider the case of transport protocols. Increases in network
performance and the use of long-lived connections have resulted in
increased vulnerability of connection-oriented transport protocols to
attacks. TCP, like many other protocols, is susceptible to off-path
third-party attacks, such as injection of a TCP RST [20]. The network
lacks comprehensive ingress filtering to drop such spoofed traffic.
These attacks can affect BGP sessions between core Internet routers,
and are thus of significant concern [2]. As a result, a number of
proposed solutions have been developed; most of these are transport
layer solutions.
Some of these solutions augment the transport protocol by improving
its own security, e.g., TCP/MD5 [5]. Others modify the core TCP
processing rules to make it harder for off-path attackers to inject
meaningful packets either during the initial handshake (e.g.
SYNcookies) or after a connection is established (e.g., TCPsecure)
[17][19]. 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) [13][18].
Touch, Wang, Black Expires August 13, 2007 [Page 6]
Internet-Draft BTNS Problem and Applicability February 2007
The TCP-specific modifications are, at best, temporary patches to the
ubiquitous vulnerability to spoofing attacks. The obvious solution to
spoofing is to validate the segments of a connection, either at the
transport layer or the network layer. The IPsec suite already
provides authentication of a network layer packet and its contents,
but the infrastructure required for deployment of IPsec can be
prohibitive.
Protecting systems from spoofed packets is ultimately an issue of
authentication, ensuring that a receiver's interpretation of the
source of a packet is accurate. Authentication validates the identity
of the source of the packet. The current IPsec suite assumes that
identity is validated either by a trusted third party - e.g., a
certification authority - or by a pre-deployed shared secret. Such an
identity is unique and invariant across associations (pair-wise
security configuration), and can be used to reject packets that are
not authentic.
There is weaker notion of identity, one which is bootstrapped from
the session association itself. The identity doesn't mean "Bill
Smith" or "owner of shared secret X2YQ", but means something more
like "the entity with which I have been communicating on connection
#23". Such identity is not invariant across associations, but because
it is invariant within an association it can still be used to provide
protection during the lifetime of that association. This is the core
notion of identity used by BTNS.
BTNS thus provides a kind of intra-association integrity, a form of
authentication where the identity is not authenticated across
separate associations or out-of-band, but does not change during the
association. This mode of BTNS is called Stand Alone BTNS (SAB),
because the protection is afforded solely by the use of BTNS
extensions, without authentication from higher layers in the protocol
stack.
With regard to BGP in particular, it has been understood that the use
of appropriate authentication is the preferred solution [2] to TCP
spoofing attacks. Supporting authentication, e.g., by using signed
certificates, at one router does not solve the problem; that router
is still at the mercy of all routers it peers with, as it depends on
them to also support authentication. The reality is that few routers
are configured to support authentication, and the result is the use
of unsecured TCP for sending BGP packets. BTNS allows an individual
router to relax the need for authentication, in order to enable the
use of protected sessions that are not authenticated. The latter is
"better than nothing" in cases where "nothing" is the alternative.
Touch, Wang, Black Expires August 13, 2007 [Page 7]
Internet-Draft BTNS Problem and Applicability February 2007
2.2.2. Authentication at Multiple Layers
Some existing protocols used on the Internet provide authentication
at a layer above the transport, but rely on the IPsec suite for
packet-by-packet cryptographic integrity and confidentiality
services. Examples of such protocols include iSCSI and the CCM mode
for NFSv4 security [15][16]. With the current IPsec suite, the
result is two authentications; one at the IPsec layer, using an
identity for IKE and an associated secret or key, and another by the
higher layer protocol using a higher layer identity and secret or
key. This is necessary if the identity and key formats differ between
IPsec and the higher layer protocol, and because there is no standard
interface to pass authentication credentials across these layers.
End-node software is then responsible for making sure that the
identities used for these two authentications are consistent in some
fashion, an authorization policy decision. In principle a single
authentication should suffice, removing the need for:
o the second authentication
o configuration and management of the identities and secrets or keys
for the second authentication
o determining in some fashion that the two authenticated identities
are consistent. Note that there are significant potential
vulnerabilities if this is not done.
IPsec is not always present for these higher layer protocols, and
even when present, will not always be used. Hence, if there is a
choice, the higher layer protocol authentication is preferable as it
will always be available for use independent of IPsec.
A "better than nothing" security approach to IPsec can address this
problem by setting up IPsec without an authentication and then
extending the higher layer authentication to establish that the
higher layer protocol session is protected by a single IPsec SA. This
counters man-in-the-middle (MITM) attacks on BTNS IPsec session
establishment by terminating the higher layer session when such an
attack occurs. This approach is based on the fact that an MITM attack
on a BTNS SA will result in two different BTNS SAs, each connecting
the MITM to one of the higher layer endpoints. These different SAs
contribute different cryptographic binding material to the higher
layer authentication, causing that authentication to fail, which
should then cause the higher layer protocol session to terminate. In
contrast to use of IKE authentication, this approach detects the man-
in-the-middle after the SAs have been set up, and hence does not
Touch, Wang, Black Expires August 13, 2007 [Page 8]
Internet-Draft BTNS Problem and Applicability February 2007
match IKE's resistance to denial of service attacks at the network
layer.
This check is referred in this document as "channel binding", thus
the name Channel Bound BTNS (CBB) [22]. Channel binding must be done
in a fashion that prevents a man-in-the-middle attack from changing
the SA identity when it is checked and from causing two different SAs
to have the same identity. Adding the SA identifier to
authentication mechanisms based on one-way hashes, key exchanges, or
(public key) cryptographic signatures are three means by which
channel binding can be accomplished with resistance to man-in-the-
middle attacks. This requires that the SA identifier be the same at
both ends of the SA [22].
Currently, the IPsec protocol suite does not define the notion of
channels for channel binding. Such channels can be constructed by
transport protocols layered above IP through cooperation between
these protocols and IPsec, to ensure that all packets for a given
channel are protected by similar SAs, where similar relates to, among
other things, the IDs of the peers. Interfaces between applications
and transport protocols are also needed for communicating channel
binding data to applications, and for applications to construct their
own IPsec channels over connection-less, datagram-oriented
transports.
3. BTNS-IPsec Overview and Threat Models
This section provides an overview of BTNS-IPsec and the security
services it offers. It also describes the modes of BTNS-IPsec.
3.1. BTNS-IPsec Overview
This is an overview of what is needed to enable BTNS-IPsec. The
detailed specifications of the extensions will be addressed by the
relevant protocol specifications.
The main update to IPsec is adding extensions to security policy that
permit secure communications with un-authenticated peers. These
extensions are necessary for both IPsec and IKE. For IPsec, the
extension applies to the PAD, which specifies the forms of
authentication for each entry ID. In addition to CA-signed X.509
certificates and pre-shared secrets, the extension adds two more
categories: un-authenticated (either null or self-signed
certificates) and channel binding, to support BTNS and BTNS with
channel binding respectively. For IKE, the AUTH payload should be
expended to allow either null payload or self-signed certificates to
match the proposed PAD extensions.
Touch, Wang, Black Expires August 13, 2007 [Page 9]
Internet-Draft BTNS Problem and Applicability February 2007
The changes to enable channel binding between IPsec and higher layer
protocols or applications will be more complex than the policy
extensions above. It will involve specifications of APIs and
interactions between IPsec and higher layer protocols. This document
assumes such provisions will eventually be developed, but does not
address their details.
3.2. BTNS-IPsec Security Services
The changes and extensions of BTNS primarily affect policy as
described above. Other parts of IPsec and IKE specifications are
unchanged. BTNS-IPsec does not establish nor does it require a
separate IPsec context. It is integrated with any existing IPsec
context in a system. The scope of BTNS-IPsec applies only to the SAs
matching the policies that explicitly specify or enable BTNS modes in
the PAD. All other non-BTNS policy entries, including entries in the
SPD and the PAD, and any non-BTNS SAs will not be affected by BTNS-
IPsec in terms of security services and requirements.
In principle, the result of removing authentication at the network
layer is that BTNS-IPsec can establish secure connections in a
fashion similar to regular IPsec and IKE, but it cannot verify or
authenticate the peer identities of these secure connections. The
following is a list of security services offered by IPsec protocol
suite. The notes address only the differences when applied to BTNS-
IPsec.
1. Access Control
Because BTNS-IPsec is integrated with any existing IPsec
contexts, the same access control mechanisms apply to BTNS-IPsec
entries in all relevant databases except that the entity IDs for
BTNS in the PAD are not authenticated. Channel bound BTNS can
authenticate after the secure connection is established at the
network layer.
2. Connectionless Integrity
3. Data Origin Authentication
4. Anti-Replay Protection
5. Confidentiality
6. (Limited) Traffic Flow Confidentiality
For the remaining security services offered by IPsec, items 2
Touch, Wang, Black Expires August 13, 2007 [Page 10]
Internet-Draft BTNS Problem and Applicability February 2007
through 6, it is possible to establish secure connections with
rogue peers in BTNS-IPsec because authentication is not required.
But once a secure connection is established, the communication is
afforded the same security services as regular IPsec.
3.3. BTNS-IPsec Modes
The previous sections have described two ways of using BTNS: Stand-
alone (SAB) or with Channel Binding (CBB). It can also be used either
symmetrically, where both parties lack network layer authentication
information, or asymmetrically, where only one party lacks the
ability to authenticate at the network layer. There are a number of
cases to consider, based on the matrix of the endpoint security
capabilities of SAB, CBB, and conventional authentication (denoted as
IKE below). The following table shows all the combinations based on
the capabilities of the two security endpoints:
| IKE | SAB | | CB-IKE | CBB |
-----+-------+-------+ -------+--------+---------+
| | | | | |
IKE | IKE | A-SAB | CB-IKE | CB-IKE | A-CBB |
| | | | | |
-----+-------+-------+ -------+--------+---------+
| | | | | |
SAB | A-SAB | S-SAB | CBB | A-CBB | S-CBB |
| | | | | |
-----+-------+-------+ -------+--------+---------+
No Channel Binding With Channel Binding
The first three modes consist of network layer authentication schemes
used without channel binding to higher layer authentication:
1. IKE: both sides possess conventional, IKE-supported authentication
2. Symmetric SAB (S-SAB, or just SAB): both sides lack network layer
authentication information
3. Asymmetric SAB (A-SAB): one side lacks network layer
authentication information, but the other possesses it
The following modes are the same as above at the network layer, but
used with channel binding to higher layer authentication credentials:
4. CB-IKE: this is the case where channel binding is used with
conventional IKE-authenticated IPsec SAs
Touch, Wang, Black Expires August 13, 2007 [Page 11]
Internet-Draft BTNS Problem and Applicability February 2007
5. Symmetric CBB (S-CBB, or just CBB): both sides lack network layer
authentication information, but channel binding is used to bind
the SAs with higher layer authentication credentials
6. Asymmetric CBB (A-CBB): this is asymmetric SAB (A-SAB) used with
channel binding; at the network layer, one side lacks network
layer authentication information and the other possesses IKE-
supported authentication, and channel binding is used to bind the
secure channel to higher layer authentication credentials
There are three security mechanisms involved in BTNS with channel
binding: BTNS-IPsec at the network layer, higher layer
authentication, and the channel binding mechanisms that bind the
higher layer authentication credentials with the secure channel (or
its corresponding abstract, cryptographic representation) presented
by BTNS-IPsec. Both BTNS-IPsec and the higher layer authentication
can be either symmetric or asymmetric, when one side lacks properly
authenticated credentials at either layer. The channel binding
mechanisms, however, must be applied at both ends of the
communication to prevent MITM attacks. Existing channel binding
mechanisms and APIs for this purpose, such as defined in GSS-API
[12], mandate the exchange and verification of the channel binding
values at both ends to ensure that correct, non-spoofed channel
characteristics are bound to the higher layer authentication.
4. Applicability Statement
BTNS is intended 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 can also
provide some level of protection for private services when the
alternative is no protection at all (as in the case of BGP, for
instance).
BTNS-IPsec uses the IPsec protocol suite, therefore should not be
used in situations where IPsec or IKE are unsuitable. IPsec and IKE
incur additional computation overhead, and IKE further requires extra
message exchanges and round-trip times to setup security
associations. These are generally undesirable in environments with
limited computational resources and/or high communication latencies.
This section provides an overview of the types of applications
suitable for various modes of BTNS. The next two sections describe
the overall benefits and vulnerabilities, followed by the
applicability analysis for each BTNS-IPsec mode. The applicability
statement covers BTNS-specific modes. IKE and CB-IKE are out of scope
for this discussion.
Touch, Wang, Black Expires August 13, 2007 [Page 12]
Internet-Draft BTNS Problem and Applicability February 2007
4.1. Benefits
BTNS protects associations once established. It reduces vulnerability
after associations have been established to attacks from parties not
participating in the association. BTNS-IPsec protects network and
transport layers without requiring network layer authentication
information. It can be deployed without pre-deployment of
authentication material for IPsec or pre-shared information, and
protects all transport layer protocols using a single mechanism.
BTNS also helps protect systems from low-effort attacks on sessions
or connections involving higher levels of resources. It raises the
level of effort for many types of network or transport layer attacks.
Casual, simple packet attacks need to be augmented to full
associations and connection establishment for SAB, so that an
attacker must perform as much work as regular host. SAB thus raises
the effort for a DDoS attack to that of emulating a flash crowd. For
open services, there may be no way to distinguish such a DDoS attack
from a legitimate flash crowd anyway.
BTNS also allows individual associations to be protected without
requiring pre-deployed authentication credentials. We anticipate that
it will use the extant, ephemeral Diffie-Hellman exchange employed in
IKE to establish pairwise secret keys between ends of an association,
effectively removing the authentication responsibility from IKE.
4.2. Vulnerabilities
BTNS removes network layer authentication. Hosts connecting to BTNS
hosts are vulnerable to communicating with a masquerader throughout
the association for SAB, or until higher layers provide additional
authentication for CBB. As a result, authentication data (e.g.,
passwords) sent to a masquerading peer could be disclosed to an
attacker. This is a deliberate design tradeoff; in BTNS, network and
transport layer access is no longer gated by the identity presented
by the other host, so this opens hosts to masquerading and flash
crowd attacks. Conversely, BTNS secures connections to hosts that
cannot authenticate at the network layer, so the network and
transport layers are more protected.
Lacking network layer authentication information, other means must be
used to provide access control for local resources. Traffic selectors
of the BTNS SPD entries can be used to limit which interfaces,
address ranges, and port ranges can access BTNS-enabled services.
Rate limiting can further restrict resource usage. For SAB, these
protections need to be considered throughout associations, whereas
for CBB they need be present only until higher layer protocols
Touch, Wang, Black Expires August 13, 2007 [Page 13]
Internet-Draft BTNS Problem and Applicability February 2007
provide the missing authentication. CCB also relies on the
effectiveness of the binding of higher layer authentication to the
BTNS network association.
4.3. Stand-Alone BTNS (SAB)
SAB is intended for applications without IKE-compatible
authentication credentials and without any higher layer protection.
It is also suitable when the identities of either party are not
important, or are deliberately omitted. This section discusses
symmetric and asymmetric SAB.
4.3.1. Symmetric SAB
Symmetric SAB (S-SAB) assumes that both parties lack network layer
authentication information and that authentication is not available
from higher layer protocols. S-SAB can still protect network and
transport protocols, but does not provide authentication at all. It
is useful where large files or long connections would benefit from
not being interrupted by DoS attacks, but where the particular
endpoint identities are not important.
Open services, such as web servers, and peer-to-peer networks could
utilize S-SAB when their identities need not be authenticated, but
where the communication would benefit from protection. Such services
might provide files either not validated or validated by other means
(e.g., published MD5 hashes). These transmissions present a target
for off-path attacks, which could be mitigated by the use of S-SAB.
S-SAB may also be useful for protecting the transport of voice-over-
IP (VoIP) between peers, such as direct calls between VoIP clients.
SAB is also useful in protecting any transport protocol when the
endpoints decide not to deploy authentication, for whatever reason.
This is the particular case for BGP TCP connections between core
routers, where the protection afforded by S-SAB is better than no
protection at all, even though BGP is not intended as an open
service.
4.3.2. Asymmetric SAB
Asymmetric SAB (A-SAB) allows one party lacking network layer
authentication information to establish associations with another
party that possesses authentication credentials, the latter by any
applicable IKE authentication mechanisms.
Asymmetric SAB is useful for protecting transport connections for
open services on the Internet, e.g., commercial web servers, etc. In
Touch, Wang, Black Expires August 13, 2007 [Page 14]
Internet-Draft BTNS Problem and Applicability February 2007
these cases, the server is typically authenticated by a widely known
CA, as is done with TLS at the application layer, but the clients
need not be authenticated [3]. Although this may result in IPsec and
TLS being used on the same connection, it is necessary because TLS
does not protect from certain spoofing attacks as described in the
problem statement section (e.g., TLS cannot prevent a spoofed TCP
RST, as the RST is processed by TCP instead of being passed to TLS).
A-SAB also secures transport for streaming media as would be used to
view broadcast streaming such as webcasts for remote education and
entertainment.
4.4. Channel-Bound BTNS (CBB)
CBB allows hosts without network layer authentication information to
cryptographically bind the BTNS-IPsec channels with authentication at
higher layers. It is intended for applications with higher layer
authentication, but could benefit from additional network layer
security to enhance protection. CBB decouples authentication from
network layer security services. With CBB, applications with IKE-
incompatible authentication credentials can access security services
provided by the IPsec security suite. CBB allows IPsec to work with
more authentication mechanisms, and frees higher layer applications
and protocols from duplicating security services already available in
IPsec.
Symmetric CBB integrates channel binding with S-SAB, as does
asymmetric CBB with A-SAB. Their target applications have similar
characteristics at the network layer to their non-channel-binding
counterparts. The only exception is the binding of authentication
credentials at higher layer to the resulting IPsec channels.
Although the modes of CBB refer to the authentication at the network
layer, higher layer authentication can also be either asymmetric
(one-way) or symmetric (two-way). Asymmetric CBB can be used to
complement one-way authentication at higher layer by providing one-
way authentication of the opposite direction at the network layer.
Consider an application with one-way, client-only authentication. The
client can utilize A-CBB where the server must present IKE-
authenticated credentials at the network layer. This form of A-CBB
achieves mutual authentication albeit at separate layers. Many remote
file system protocols, such as iSCSI and NFS, fit into this category,
and can benefit from channel binding with IPsec for better network
layer protection and to ensure no MITM attacks.
Mechanisms and interfaces for channel binding with IPsec are
discussed in further detail in [22].
Touch, Wang, Black Expires August 13, 2007 [Page 15]
Internet-Draft BTNS Problem and Applicability February 2007
4.5. 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 Same as SAB but plus
Peer-to-peer higher layer auth, e.g.
Zero-config Infrastructure iSCSI [15], Kerberos [11]
Vuln. Masqueraders Masqueraders until bound
Needs data rate limit Needs data 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 mostly 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.
5. Security Considerations
This section presents the threat models for BTNS, and discusses other
security issues based on the threat models for different modes of
BTNS. Some of the issues were mentioned previously in the document,
but are listed again for completeness.
5.1. Threat Models and Evaluation
BTNS is intended to protect sessions from a variety of threats,
including on-path, man-in-the-middle attacks after key exchange,
other on-path attacks after key exchange, and off-path attacks. It is
intended to protect the contents of a session once established using
a "leap of faith" authentication during session establishment, but
does not protect session establishment itself.
BTNS is not intended to protect the key exchange itself, so this
presents an opportunity for a man-in-the-middle attack or a well-
timed attack from other sources. Furthermore, Stand-alone BTNS is not
intended to protect the endpoint from nodes masquerading as
legitimate clients. Channel-Bound BTNS can protect from such
Touch, Wang, Black Expires August 13, 2007 [Page 16]
Internet-Draft BTNS Problem and Applicability February 2007
masquerading, though at a later point after the security association
is established.
BTNS is also not intended to protect from DoS attacks that seek to
overload a CPU performing authentication and other security
computations, nor is it intended to protect from configuration
mistakes. These final assumptions are the same as that of the IP
network protocol security suite. Finally, manual keying is not
considered in because it is unsafe for protocols that exchange large
amounts of traffic such as IP Storage (e.g., RFC-3723 forbids use of
manual keying with the IP Storage protocols) [1].
The following sections discuss the implications of the threat models
in more details.
5.2. Interaction with Other Extant Security
As with any aspect of network security, the use of BTNS must not
interfere with extant security services. Within an IPsec context, the
scope of BTNS must be limited to the SPD and PAD entries that
explicitly specify BTNS, and to the resulting SAD entries. It is
incumbent on system administrators to deploy BTNS only where safe,
preferably as a substitute to the use of "bypass" which exempts
specified traffic from IPsec cryptograph protection. In other words,
BTNS should be used only as a substitute for no security, rather than
as a substitute for stronger security. This is particularly relevant
for the use of BTNS for BGP. Full authentication is preferred for
BGP. When that is not available, other methods, such as IP address
filtering, can help reduce the vulnerability of SAB to exposure to
anonymous access.
5.3. MITM and Masquerader Attacks
Previous sections have described how CBB can counter MITM and
masquerader attacks, even though BTNS does not protect key exchange
nor does it authenticate peer identities at the network layer.
Nonetheless, there are some security issues regarding CBB that must
be carefully evaluated before deploying BTNS.
For regular IPsec/IKE, 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. On the other hand, a man-in-the-middle attack on IPsec with
CBB is discovered later than if IKE authentication were used. With
CBB, the BTNS-IKE step will succeed because it is unauthenticated,
and the security association will be set up. The man in the middle
will not be discovered until the higher layer authentication fails.
Touch, Wang, Black Expires August 13, 2007 [Page 17]
Internet-Draft BTNS Problem and Applicability February 2007
There are two security concerns with this approach: possible exposure
of sensitive authentication information to the attackers, and
resource consumption before attacks are detected.
The exposure of information depends on the higher layer
authentication protocols used in applications. If the higher layer
authentication requires exchange of sensitive information (e.g.,
password-derived materials) that can be attacked offline, the
attackers can gain such information even though they will be
detected. Therefore, CBB must not be used with higher layer protocols
that may expose sensitive information during authentication exchange.
For example, Kerberos V AP exchanges would leak little other than the
target's krb5 principal name, while Kerberos V AS exchanges using PA-
ENC-TIMESTAMP pre-authentication would leak material that can then be
attacked offline. The latter should not be used with BTNS, even with
Channel Binding. 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.
The resource consumption issue is addressed in the next section on
DoS attacks.
5.4. DoS Attacks and Resource Consumptions
BTNS deployment means that more traffic will require cryptographic
operations, which increase the load on those receiving protected
traffic and/or verifying incoming traffic. The additional computation
raises vulnerability to overloading, which can be the result of
legitimate flash crowds or from zombies utilized in DoS attacks.
Although this may itself present a substantial impediment to
deployment, it is a challenge to all cryptographically protected
communication systems, and BTNS does not create or amplify that
aspect per se. This document does not address the impact BTNS has on
such load.
The effects of the increased resource consumption are twofold. It
raises the level of effort for attackers such as MITM, but it also
consumes more resources to detect such attacks or to reject spoofed
traffic. At the network layer, proper limits or access controls for
resources should be setup for all BTNS sessions. CBB sessions can be
granted with better access once the higher layer authentications
succeed. The same principles apply to the higher layer protocols in
the CBB sessions. Special care must be taken to avoid undue resource
usage before the authentication is established in the applications.
Touch, Wang, Black Expires August 13, 2007 [Page 18]
Internet-Draft BTNS Problem and Applicability February 2007
5.5. Exposure to Anonymous Access
The use of SAB necessarily implies that a service is being offered
for open access, since network layer authentication information is
not available. SAB must not be used with services that are not
intended to be openly available.
5.6. ICMP Attacks
This document does not consider ICMP attacks because the use of BTNS-
IPsec does not change the existing guideline [9] on how ICMP traffic
is handled. BTNS-IPsec focuses on authentication part of establishing
security associations. It does not alter the IPsec traffic processing
model and protection boundary. As a result, the entire IPsec packet
processing guidelines, including ICMP processing, remain the same for
BTNS-IPsec.
5.7. Leap of Faith
BTNS allows systems to accept and establish security associations
with peers without authenticating their identities. This can enable
functionality similar to "Leap of Faith" utilized in other security
protocols and applications such as SSH [23].
SSH implementations may accept unknown peer credentials (host public
keys) without authentication, and the applications are further
allowed to cache these unauthenticated credentials in local databases
for future authentication of the same peers. Similar to BTNS, such
measures are allowed due to the lack of 'widely deployed key
infrastructure' [23] and to improve ease of use and end-user
acceptance. There are still subtle differences. The following table
compares the behaviors of SSH and BTNS regarding Leap of Faith.
| SSH | BTNS |
-------------------------------+---------+---------+
Accept unauthenticated | Yes | Yes |
Credentials | | |
-------------------------------+---------+---------+
Options/Warnings to reject | Yes | No |
unauthenticated credentials | | |
-------------------------------+---------+---------+
Cache unauthenticated | Yes | No |
credential for future refs | | |
-------------------------------+---------+---------+
SSH requires proper warnings and options in the applications to
reject unauthenticated credentials, while BTNS will accept those
Touch, Wang, Black Expires August 13, 2007 [Page 19]
Internet-Draft BTNS Problem and Applicability February 2007
automatically if they match the corresponding policy entries. Once
SSH accepts a credential for the first time, it should be cached, and
can be reused automatically without further warnings.
On the other hand, there are two key issues with BTNS-IPsec: whether
to cache credentials and if so, how to treat cached credentials. The
main reason to cache a credential is to treat it differently the next
time it appears. For SAB without Channel Binding, the credentials
should not be cached because they remain unauthenticated, and BTNS-
IPsec does not require IPsec to reuse credentials in a manner similar
to SSH. For CBB, credential caching and verification are usually done
at the higher layer protocols or applications, as well be discussed
in the next section. Caching credentials at the BTNS-IPsec is not as
important because the channel binding will bind whatever credentials
are presented (new or cached) to the higher layer protocol identity.
SSH-style credential caching for reuse with SAB can be added as a
future extension to BTNS-IPsec; such work would need to provide
warnings and checks on unauthenticated credentials in order to
establish a level of assurance of authentication compared to SSH's
"Leap of Faith."
5.8. Connection Hijacking through Rekeying
Each IPsec SA has a limited lifetime (defined as a time and/or byte
count), and it must be rekeyed or terminated when the lifetime
expires. Rekeying SA provides a small window of opportunity where an
on-path attacker can step in and hijack the connection by spoofing
the victim during rekeying. This vulnerability affects both regular
IPsec and BTNS, although BTNS, more specifically SAB, makes it easier
to spoof without authentication. CBB, on the other hand, can detect
such attacks by detect the changes in the secure channel properties
as will be described later.
To hijack an existing SA (ESP or AH) between Alice and Bob (victim),
Charles (attacker) must posses credentials that match to the same
entry in Alice's PAD as Bob. It is possible because of wildcards in
PAD entry IDs, though the authentication requirements of the regular
IPsec do provide more of a hurdle to the attackers than BTNS-IPsec.
The attacker, Charles, must initiate the attack when the IKE SA
between Alice and Bob expires; or the existing IKE SA would protect
the rekeying from spoofing attacks. After the IKE SA has expired,
Charles can spoof Bob to create a new IKE SA and subsequent CHILD SAs
with Alice through the same PAD entry. It requires precise timing,
and the attacker must be able to block the IKE rekeying requests
between Alice and Bob.
Touch, Wang, Black Expires August 13, 2007 [Page 20]
Internet-Draft BTNS Problem and Applicability February 2007
The problem is the lack of inter-session binding or latching of IKE
SAs with the corresponding credentials of the two peers. Connection
latching [21], together with channel binding, enables such binding,
but requires upper layer protocols or applications to verify the
consistency across IKE sessions. Connection latching defines a set of
SA parameters, along with corresponding peer identities and
authentication data, as a representation of a secure channel. It
provides this data to the upper layer protocols that wish to "latch"
on to the channel. Channel binding binds this secure channel (or
"latch") to higher layer authentication. It is the upper layer
protocols or applications that determine whether to cache and verify
the consistency of the peer identities across sessions. If the upper
layer session is still active, channel binding will lock down the
channel and prevent the spoofing attack. If the upper layer session
has also expired, it will require re-authentication at the higher
layer. The later re-authentication and binding should prevent the
spoofing whether or not the BTNS-IPsec credentials are cached.
Without the additional session information from higher layer
protocols, it is very difficult for network layer protocols such as
IPsec to predict the lengths of connections and to distinguish
between legitimate changes of peers vs. spoofing.
In summary, connection latching defines the notion of a secure
channel, and channel binding enables higher layer protocol to bind
its authentication to this secure channel. Caching of this "latch"
across session is necessary to counter inter-session spoofing
attacks, and can be done at either the BTNS-IPsec layer or at the
higher layer.
5.9. Configuration Errors
BTNS does not address errors of configuration that could result in
increased vulnerability; such vulnerability is already possible using
"bypass". This work presumes that associations using BTNS will
consist of SPD entries, just as "bypass," therefore separated from
associations with more conventional, stronger security.
6. Other Issues and Related Efforts
This section discusses other issues not included in any previous
categories, and lists the related work.
6.1. NAT Traversal
The issues regarding NAT traversal are mostly orthogonal to BTNS
because BTNS focuses on relaxing peer authentication in IKE and IPsec
policy. BTNS with Channel Binding may cause problems with NAT if the
Touch, Wang, Black Expires August 13, 2007 [Page 21]
Internet-Draft BTNS Problem and Applicability February 2007
IDs are tied to addresses at the application layer. Note that this
problem is not specific to BTNS, but rather to the design of generic
IPsec Channel Binding APIs. Therefore, this document does not
consider the impact of NAT or NAPT on the capabilities it intends to
provide, except as are already addressed by the current IPsec
specifications.
6.2. Mobility and Multihoming
BTNS does not consider the impact of mobility or multihoming on the
capabilities it intends to provide.
6.3. Related IETF Efforts
There are a number of related efforts in the IETF and elsewhere to
reduce the configuration effort of deploying the Internet security
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 automatic discovery of hosts willing to do a BTNS-
like encryption, with authentication being exchanged by leveraging
existing use of the DNS [14]. BTNS differs from all three in that
BTNS is intended to avoid the need for such infrastructure
altogether, rather than to automate it.
7. IANA Considerations
There are no IANA issues in this document.
This section should be removed by the RFC-Editor prior to final
publication.
8. Acknowledgments
This document was inspired by discussions on the IETF TCPM WG about
the recent spoofed RST attacks on BGP routers and various solutions,
as well as discussions in the nfsv4 and ips WGs about how to better
integrate with IPsec. The concept of BTNS was the result of these
discussions as well as with USC/ISI's T. Faber, A. Falk, and B. Tung,
and discussions on the IETF SAAG WG and IPsec mailing list. The
Touch, Wang, Black Expires August 13, 2007 [Page 22]
Internet-Draft BTNS Problem and Applicability February 2007
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, Sam Hartman, Nicolas Williams, and Pekka
Savola.
This document was prepared using 2-Word-v2.0.template.dot.
9. References
9.1. Normative References
(none)
9.2. Informative References
[1] Aboba, B., J. Tseng, J. Walker, V. Rangan, and F. Travostino,
"Securing Block Storage Protocols over IP," RFC-3723, April
2004.
[2] CERT Vulnerability Note VU#415294, "The Border Gateway Protocol
relies on persistent TCP sessions without specifying
authentication requirements," 4/20/2004.
[3] Dierks, T. E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1," RFC-4346, April 2006.
[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] Kaufman, C., (ed.), "Internet Key Exchange (IKEv2) Protocol,"
RFC-4306, Dec. 2005.
[9] Kent, S., R. Atkinson, "Security Architecture for the Internet
Protocol," RFC-2401, Nov. 1998.
[10] Kent, S., K. Seo, "Security Architecture for the Internet
Protocol," RFC-4301, Dec. 2005.
Touch, Wang, Black Expires August 13, 2007 [Page 23]
Internet-Draft BTNS Problem and Applicability February 2007
[11] Kohl, J., C. Neuman, "The Kerberos Network Authentication
Service (V5)," RFC-1510, Sep. 1993.
[12] Linn, J, "Generic Security Service Application Program
Interface Version 2, Update 1," RFC-2743, Jan. 2000.
[13] Mostkowitz, R., P. Nikander, P. Jokela (ed.), T. Henderson,
"Host Identity Protocol," (work in progress),
draft-ietf-hip-base-06, Jun. 2006.
[14] Richardson, M., Redelmeier, D., "Opportunistic Encryption using
The Internet Key Exchange (IKE)," RFC-4322, Dec. 2005.
[15] Satran, J., K. Meth, C. Sapuntzakis, M. Chadalapaka, E.
Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
RFC-3720, April 2004.
[16] Shepler, S., B. Callaghan, D. Robinson, R. Thurlow, C., Beame,
M. Eisler, D. Noveck, "Network File System (NFS) version 4
Protocol," RFC-3530, April, 2003.
[17] Steward, R., Dalal, M., "Improving TCP's Robustness to Blind
In-Window Attacks," (work in progress),
draft-ietf-tcpm-tcpsecure-05, Jun. 2006.
[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-05.txt, Sept. 2006.
[21] Williams, N., "IPsec Channels: Connection Latching," (work in
progress), draft-ietf-btns-connection-latching-00, Feb. 2006.
[22] Williams, N., "On the Use of Channel Bindings to Secure
Channels," (work in progress),
draft-williams-on-channel-binding-00, Jun. 2006.
[23] Ylonen, T, Lonvick, C. (ed.), "The Secure Shell (SSH) Protocol
Architecture," RFC-4251, Jan. 2006.
Touch, Wang, Black Expires August 13, 2007 [Page 24]
Internet-Draft BTNS Problem and Applicability February 2007
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
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
Touch, Wang, Black Expires August 13, 2007 [Page 25]
Internet-Draft BTNS Problem and Applicability February 2007
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, THE IETF TRUST 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 IETF Trust (2007).
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, Wang, Black Expires August 13, 2007 [Page 26]
