One document matched: draft-nir-saag-rfc3552bis-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY rfc4033 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc2946 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2946.xml">
<!ENTITY rfc4303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY rfc2743 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY rfc7230 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY rfc2818 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY rfc2403 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2403.xml">
<!ENTITY rfc4120 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY rfc2289 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2289.xml">
<!ENTITY rfc2522 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2522.xml">
<!ENTITY rfc5280 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc7322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7322.xml">
<!ENTITY rfc2505 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2505.xml">
<!ENTITY rfc5231 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5231.xml">
<!ENTITY rfc4422 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY rfc2693 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2693.xml">
<!ENTITY rfc4954 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4954.xml">
<!ENTITY rfc3207 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml">
<!ENTITY rfc2660 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2660.xml">
<!ENTITY rfc5751 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY rfc0854 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0854.xml">
<!ENTITY rfc5322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY rfc5246 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc2817 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2817.xml">
<!ENTITY rfc1738 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1738.xml">
<!ENTITY rfc5798 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5798.xml">
<!ENTITY rfc4253 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY rfc1414 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1414.xml">
<!ENTITY rfc1704 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1704.xml">
<!ENTITY rfc3977 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3977.xml">
<!ENTITY rfc0791 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY rfc1939 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY rfc5406 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5406.xml">
<!ENTITY rfc5925 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml">
]>
<?rfc toc="yes"?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc rfcedstyle="yes"?>
<rfc ipr="trust200902" docName="draft-nir-saag-rfc3552bis-00" category="std">
<front>
<title abbrev="Security Considerations Guidelines">Guidelines for Writing RFC Text on Security Considerations</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>6789735</code>
<country>Israel</country>
</postal>
<email>ynir.ietf@gmail.com</email>
</address>
</author>
<author initials='M.' surname='Westerlund' fullname='Magnus Westerlund'>
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<code>SE-164 80</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<date year="2016"/>
<area>Security Area</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t> All RFCs are required to have a Security Considerations section. Historically,
such sections have been relatively weak. This document provides guidelines to
RFC authors on how to write a good Security Considerations section.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> All RFCs are required by <xref target="RFC7322"/> to contain a Security
Considerations section. The purpose of this is both to encourage document authors
to consider security in their designs and to inform the reader of relevant
security issues. This memo is intended to provide guidance to RFC authors in
service of both ends.</t>
<t> This document is structured in three parts. The first is a combination
security tutorial and definition of common terms; the second is a series of
guidelines for writing Security Considerations; the third is a series of
examples.</t>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<t> 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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section anchor="goals" title="The Goals of Security">
<t> Most people speak of security as if it were a single monolithic property of a
protocol or system, however, upon reflection, one realizes that it is clearly not
true. Rather, security is a series of related but somewhat independent properties.
Not all of these properties are required for every application.</t>
<t> We can loosely divide security goals into those related to protecting
communications (COMMUNICATION SECURITY, also known as COMSEC) and those relating
to protecting systems (ADMINISTRATIVE SECURITY or SYSTEM SECURITY). Since
communications are carried out by systems and access to systems is through
communications channels, these goals obviously interlock, but they can also be
independently provided.</t>
<section anchor="comsec" title="Communication Security">
<t> Different authors partition the goals of communication security differently.
The partitioning we've found most useful is to divide them into three major
categories: CONFIDENTIALITY, DATA INTEGRITY and PEER ENTITY AUTHENTICATION.</t>
<section anchor="csconf" title="Confidentiality">
<t> When most people think of security, they think of CONFIDENTIALITY.
Confidentiality means that your data is kept secret from unintended
listeners. Usually, these listeners are simply eavesdroppers. When an
adversary taps your phone, it poses a risk to your confidentiality.</t>
<t> Obviously, if you have secrets, then you are probably concerned about
others discovering them. Thus, at the very least, you want to maintain
confidentiality. When you see spies in the movies go into the bathroom and
turn on all the water to foil bugging, the property they're looking for is
confidentiality.</t>
</section>
<section anchor="csdi" title="Data Integrity">
<t> The second primary goal is DATA INTEGRITY. The basic idea here is that we
want to make sure that the data we receive is the same data that the sender
has sent. In paper-based systems, some data integrity comes automatically.
When you receive a letter written in pen you can be fairly certain that no
words have been removed by an attacker because pen marks are difficult to
remove from paper. However, an attacker could have easily added some marks to
the paper and completely changed the meaning of the message. Similarly, it's
easy to shorten the page to truncate the message.</t>
<t> On the other hand, in the electronic world, since all bits look alike, it's
trivial to tamper with messages in transit. You simply remove the message
from the wire, copy out the parts you like, add whatever data you want, and
generate a new message of your choosing, and the recipient is no wiser. This
is the moral equivalent of the attacker taking a letter you wrote, buying some
new paper and recopying the message, changing it as he does it. It's just a
lot easier to do electronically since all bits look alike.</t>
</section>
<section anchor="cspeerauth" title="Peer Entity Authentication">
<t> The third property we're concerned with is PEER ENTITY AUTHENTICATION. What
we mean by this is that we know that one of the endpoints in the communication
is the one we intended. Without peer entity authentication, it's very
difficult to provide either confidentiality or data integrity. For instance,
if we receive a message from Alice, the property of data integrity doesn't do
us much good unless we know that it was in fact sent by Alice and not the
attacker. Similarly, if we want to send a confidential message to Bob, it's
not of much value to us if we're actually sending a confidential message to
the attacker.</t>
<t> Note that peer entity authentication can be provided asymmetrically. When
you call someone on the phone, you can be fairly certain that you have the
right person -- or at least that you got a person who's actually at the phone
number you called. On the other hand, if they don't have caller ID, then the
receiver of a phone call has no idea who's calling them. Calling someone on
the phone is an example of recipient authentication, since you know who the
recipient of the call is, but they don't know anything about the sender.</t>
<t> In messaging situations, you often wish to use peer entity authentication
to establish the identity of the sender of a certain message. In such
contexts, this property is called DATA ORIGIN AUTHENTICATION.</t>
</section>
</section>
<section anchor="nonrep" title="Non-Repudiation">
<t> A system that provides endpoint authentication allows one party to be certain
of the identity of someone with whom he is communicating. When the system
provides data integrity a receiver can be sure of both the sender's identity
and that he is receiving the data that that sender meant to send. However, he
cannot necessarily demonstrate this fact to a third party. The ability to make
this demonstration is called NON-REPUDIATION.</t>
<t> There are many situations in which non-repudiation is desirable. Consider the
situation in which two parties have signed a contract which one party wishes to
unilaterally abrogate. He might simply claim that he had never signed it in
the first place. Non-repudiation prevents him from doing so, thus protecting
the counterparty.</t>
<t> Unfortunately, non-repudiation can be very difficult to achieve in practice
and naive approaches are generally inadequate. <xref target="nonrepu" />
describes some of the difficulties, which generally stem from the fact that the
interests of the two parties are not aligned -- one party wishes to prove
something that the other party wishes to deny.</t>
</section>
<section anchor="syssec" title="Systems Security">
<t> In general, systems security is concerned with protecting one's machines and
data. The intent is that machines should be used only by authorized users and
for the purposes that the owners intend. Furthermore, they should be available
for those purposes. Attackers should not be able to deprive legitimate users
of resources.</t>
<section anchor="unauth" title="Unauthorized Usage">
<t> Most systems are not intended to be completely accessible to the public.
Rather, they are intended to be used only by certain authorized individuals.
Although many Internet services are available to all Internet users, even
those servers generally offer a larger subset of services to specific users.
For instance, Web Servers often will serve data to any user, but restrict the
ability to modify pages to specific users. Such modifications by the general
public would be UNAUTHORIZED USAGE.</t>
</section>
<section anchor="inapp" title="Inappropriate Usage">
<t> Being an authorized user does not mean that you have free run of the system.
As we said above, some activities are restricted to authorized users, some to
specific users, and some activities are generally forbidden to all but
administrators. Moreover, even activities which are in general permitted
might be forbidden in some cases. For instance, users may be permitted to
send email but forbidden from sending files above a certain size, or files
which contain viruses. These are examples of INAPPROPRIATE USAGE.</t>
</section>
<section anchor="dos" title="Denial of Service">
<t> Recall that our third goal was that the system should be available to
legitimate users. A broad variety of attacks are possible which threaten
such usage. Such attacks are collectively referred to as DENIAL OF SERVICE
attacks. Denial of service attacks are often very easy to mount and
difficult to stop. Many such attacks are designed to consume machine
resources, making it difficult or impossible to serve legitimate users. Other
attacks cause the target machine to crash, completely denying service to
users.</t>
</section>
</section>
</section>
<section anchor="itm" title="The Internet Threat Model">
<t> A THREAT MODEL describes the capabilities that an attacker is assumed to be
able to deploy against a resource. It should contain such information as the
resources available to an attacker in terms of information, computing capability,
and control of the system. The purpose of a threat model is twofold. First, we
wish to identify the threats we are concerned with. Second, we wish to rule some
threats explicitly out of scope. Nearly every security system is vulnerable to a
sufficiently dedicated and resourceful attacker.</t>
<t> The Internet environment has a fairly well understood threat model. In general,
we assume that the end-systems engaging in a protocol exchange have not themselves
been compromised. Protecting against an attack when one of the end-systems has
been compromised is extraordinarily difficult. It is, however, possible to design
protocols which minimize the extent of the damage done under these circumstances.</t>
<t> By contrast, we assume that the attacker has nearly complete control of the
communications channel over which the end-systems communicate. This means that
the attacker can read any PDU (Protocol Data Unit) on the network and undetectably
remove, change, or inject forged packets onto the wire. This includes being able
to generate packets that appear to be from a trusted machine. Thus, even if the
end-system with which you wish to communicate is itself secure, the Internet
environment provides no assurance that packets which claim to be from that system
in fact are.</t>
<t> It's important to realize that the meaning of a PDU is different at different
levels. At the IP level, a PDU means an IP packet. At the TCP level, it means a
TCP segment. At the application layer, it means some kind of application PDU. For
instance, at the level of email, it might either mean an <xref target="RFC5322" />
message or a single SMTP command. At the HTTP level, it might mean a request or
response.</t>
<section anchor="ltm" title="Limited Threat Models">
<t> As we've said, a resourceful and dedicated attacker can control the entire
communications channel. However, a large number of attacks can be mounted by an
attacker with fewer resources. A number of currently known attacks can be
mounted by an attacker with limited control of the network. For instance,
password sniffing attacks can be mounted by an attacker who can only read
arbitrary packets. This is generally referred to as a PASSIVE ATTACK <xref
target="RFC1704" />.</t>
<t> By contrast, Morris' sequence number guessing attack <xref target="SEQNUM" />
can be mounted by an attacker who can write but not read arbitrary packets. Any
attack which requires the attacker to write to the network is known as an ACTIVE
ATTACK.</t>
<t> Thus, a useful way of organizing attacks is to divide them based on the
capabilities required to mount the attack. The rest of this section describes
these categories and provides some examples of each category.</t>
</section>
<section anchor="passive" title="Passive Attacks">
<t> In a passive attack, the attacker reads packets off the network but does not
write them. The simplest way to mount such an attack is to simply be on the
same LAN as the victim. On most common LAN configurations, including Ethernet,
802.3, and FDDI, any machine on the wire can read all traffic destined for any
other machine on the same LAN. Note that switching hubs make this sort of
sniffing substantially more difficult, since traffic destined for a machine only
goes to the network segment which that machine is on.</t>
<t> Similarly, an attacker who has control of a host in the communications path
between two victim machines is able to mount a passive attack on their
communications. It is also possible to compromise the routing infrastructure to
specifically arrange that traffic passes through a compromised machine. This
might involve an active attack on the routing infrastructure to facilitate a
passive attack on a victim machine.</t>
<t> Wireless communications channels deserve special consideration, especially
with the recent and growing popularity of wireless-based LANs, such as those
using 802.11. Since the data is simply broadcast on well known radio
frequencies, an attacker simply needs to be able to receive those transmissions.
Such channels are especially vulnerable to passive attacks. Although many such
channels include cryptographic protection, it is often of such poor quality as
to be nearly useless <xref target="WEP"/>.</t>
<t> In general, the goal of a passive attack is to obtain information which the
sender and receiver would prefer to remain private. This private information
may include credentials useful in the electronic world and/or passwords or
credentials useful in the outside world, such as confidential business
information.</t>
<section anchor="confid" title="Confidentiality Violations">
<t> The classic example of passive attack is sniffing some inherently private
data off of the wire. For instance, despite the wide availability of SSL,
many credit card transactions still traverse the Internet in the clear. An
attacker could sniff such a message and recover the credit card number, which
can then be used to make fraudulent transactions. Moreover, confidential
business information is routinely transmitted over the network in the clear in
email.</t>
</section>
<section anchor="sniff" title="Password Sniffing">
<t> Another example of a passive attack is PASSWORD SNIFFING. Password sniffing
is directed towards obtaining unauthorized use of resources. Many protocols,
including TELNET <xref target="RFC0854" />, POP <xref target="RFC1939" />, and
NNTP <xref target="RFC3977" /> use a shared password to authenticate the client
to the server. Frequently, this password is transmitted from the client to the
server in the clear over the communications channel. An attacker who can read
this traffic can therefore capture the password and REPLAY it. In other
words, the attacker can initiate a connection to the server and pose as the
client and login using the captured password.</t>
<t> Note that although the login phase of the attack is active, the actual
password capture phase is passive. Moreover, unless the server checks the
originating address of connections, the login phase does not require any
special control of the network.</t>
</section>
<section anchor="offline" title="Offline Cryptographic Attacks">
<t> Many cryptographic protocols are subject to OFFLINE ATTACKS. In such a
protocol, the attacker recovers data which has been processed using the
victim's secret key and then mounts a cryptanalytic attack on that key.
Passwords make a particularly vulnerable target because they are typically low
entropy. A number of popular password-based challenge response protocols are
vulnerable to DICTIONARY ATTACK. The attacker captures a challenge-response
pair and then proceeds to try entries from a list of common words (such as a
dictionary file) until he finds a password that produces the right response.</t>
<t> A similar such attack can be mounted on a local network when NIS is used.
The Unix password is crypted using a one-way function, but tools exist to
break such crypted passwords <xref target="KLEIN"/>. When NIS is used, the
crypted password is transmitted over the local network and an attacker can
thus sniff the password and attack it.</t>
<t> Historically, it has also been possible to exploit small operating system
security holes to recover the password file using an active attack. These
holes can then be bootstrapped into an actual account by using the
aforementioned offline password recovery techniques. Thus we combine a
low-level active attack with an offline passive attack.</t>
</section>
</section>
<section anchor="active" title="Active Attacks">
<t> When an attack involves writing data to the network, we refer to this as an
ACTIVE ATTACK. When IP is used without IPsec, there is no authentication for
the sender address. As a consequence, it's straightforward for an attacker to
create a packet with a source address of his choosing. We'll refer to this as a
SPOOFING ATTACK.</t>
<t> Under certain circumstances, such a packet may be screened out by the network.
For instance, many packet filtering firewalls screen out all packets with source
addresses on the INTERNAL network that arrive on the EXTERNAL interface. Note,
however, that this provides no protection against an attacker who is inside the
firewall. In general, designers should assume that attackers can forge packets.</t>
<t> However, the ability to forge packets does not go hand in hand with the
ability to receive arbitrary packets. In fact, there are active attacks that
involve being able to send forged packets but not receive the responses. We'll
refer to these as BLIND ATTACKS.</t>
<t> Note that not all active attacks require forging addresses. For instance, the
TCP SYN denial of service attack <xref target="TCPSYN"/> can be mounted
successfully without disguising the sender's address. However, it is common
practice to disguise one's address in order to conceal one's identity if an
attack is discovered.</t>
<t> Each protocol is susceptible to specific active attacks, but experience shows
that a number of common patterns of attack can be adapted to any given protocol.
The next sections describe a number of these patterns and give specific examples
of them as applied to known protocols.</t>
</section>
<section anchor="replay" title="Replay Attacks">
<t> In a REPLAY ATTACK, the attacker records a sequence of messages off of the
wire and plays them back to the party which originally received them. Note
that the attacker does not need to be able to understand the messages. He
merely needs to capture and retransmit them.</t>
<t> For example, consider the case where an S/MIME message is being used to
request some service, such as a credit card purchase or a stock trade. An
attacker might wish to have the service executed twice, if only to
inconvenience the victim. He could capture the message and replay it, even
though he can't read it, causing the transaction to be executed twice.</t>
</section>
<section anchor="insertion" title="Message Insertion">
<t> In a MESSAGE INSERTION attack, the attacker forges a message with some
chosen set of properties and injects it into the network. Often this message
will have a forged source address in order to disguise the identity of the
attacker.</t>
<t> For example, a denial-of-service attack can be mounted by inserting a series
of spurious TCP SYN packets directed towards the target host. The target host
responds with its own SYN and allocates kernel data structures for the new
connection. The attacker never completes the 3-way handshake, so the
allocated connection endpoints just sit there taking up kernel memory. Typical
TCP stack implementations only allow some limited number of connections in
this "half-open" state and when this limit is reached, no more connections can
be initiated, even from legitimate hosts. Note that this attack is a blind
attack, since the attacker does not need to process the victim's SYNs.</t>
</section>
<section anchor="deletion" title="Message Deletion">
<t> In a MESSAGE DELETION attack, the attacker removes a message from the wire.
Morris' sequence number guessing attack <xref target="SEQNUM"/> often requires
a message deletion attack to be performed successfully. In this blind attack,
the host whose address is being forged will receive a spurious TCP SYN packet
from the host being attacked. Receipt of this SYN packet generates a RST,
which would tear the illegitimate connection down. In order to prevent this
host from sending a RST so that the attack can be carried out successfully,
Morris describes flooding this host to create queue overflows such that the
SYN packet is lost and thus never responded to.</t>
</section>
<section anchor="modification" title="Message Modification">
<t> In a MESSAGE MODIFICATION attack, the attacker removes a message from the
wire, modifies it, and reinjects it into the network. This sort of attack is
particularly useful if the attacker wants to send some of the data in the
message but also wants to change some of it.</t>
<t> Consider the case where the attacker wants to attack an order for goods
placed over the Internet. He doesn't have the victim's credit card number so
he waits for the victim to place the order and then replaces the delivery
address (and possibly the goods description) with his own. Note that this
particular attack is known as a CUT-AND-PASTE attack since the attacker cuts
the credit card number out of the original message and pastes it into the new
message.</t>
<t> Another interesting example of a cut-and-paste attack is provided by <xref
target="IPSPPROB"/>. If IPsec ESP is used without any MAC then it is possible
for the attacker to read traffic encrypted for a victim on the same machine.
The attacker attaches an IP header corresponding to a port he controls onto
the encrypted IP packet. When the packet is received by the host it will
automatically be decrypted and forwarded to the attacker's port. Similar
techniques can be used to mount a session hijacking attack. Both of these
attacks can be avoided by always using message authentication when you use
encryption. Note that this attack only works if (1) no MAC check is being
used, since this attack generates damaged packets (2) a host-to-host SA is
being used, since a user-to-user SA will result in an inconsistency between
the port associated with the SA and the target port. If the receiving machine
is single-user than this attack is infeasible.</t>
</section>
<section anchor="mitm" title="Man-In-The-Middle">
<t> A MAN-IN-THE-MIDDLE attack combines the above techniques in a special form:
The attacker subverts the communication stream in order to pose as the sender
to receiver and the receiver to the sender:</t><figure><artwork><![CDATA[
What Alice and Bob think:
Alice <----------------------------------------------> Bob
What's happening:
Alice <----------------> Attacker <----------------> Bob
]]></artwork></figure>
<t> This differs fundamentally from the above forms of attack because it attacks
the identity of the communicating parties, rather than the data stream itself.
Consequently, many techniques which provide integrity of the communications
stream are insufficient to protect against man-in-the-middle attacks.</t>
<t> Man-in-the-middle attacks are possible whenever a protocol lacks PEER ENTITY
AUTHENTICATION. For instance, if an attacker can hijack the client TCP
connection during the TCP handshake (perhaps by responding to the client's SYN
before the server does), then the attacker can open another connection to the
server and begin a man-in-the-middle attack. It is also trivial to mount
man-in-the-middle attacks on local networks via ARP spoofing -- the attacker
forges an ARP with the victim's IP address and his own MAC address. Tools to
mount this sort of attack are readily available.</t>
<t> Note that it is only necessary to authenticate one side of the transaction
in order to prevent man-in-the-middle attacks. In such a situation the the
peers can establish an association in which only one peer is authenticated. In
such a system, an attacker can initiate an association posing as the
unauthenticated peer but cannot transmit or access data being sent on a
legitimate connection. This is an acceptable situation in contexts such as Web
e-commerce where only the server needs to be authenticated (or the client is
independently authenticated via some non-cryptographic mechanism such as a
credit card number).</t>
</section>
<section anchor="topo" title="Topological Issues">
<t> In practice, the assumption that it's equally easy for an attacker to read and
generate all packets is false, since the Internet is not fully connected. This
has two primary implications.</t>
<section anchor="offpath" title="On-path versus off-path">
<t> In order for a datagram to be transmitted from one host to another, it
generally must traverse some set of intermediate links and gateways. Such
gateways are naturally able to read, modify, or remove any datagram
transmitted along that path. This makes it much easier to mount a wide
variety of attacks if you are on-path.</t>
<t> Off-path hosts can, of course, transmit arbitrary datagrams that appear to
come from any hosts but cannot necessarily receive datagrams intended for
other hosts. Thus, if an attack depends on being able to receive data,
off-path hosts must first subvert the topology in order to place themselves
on-path. This is by no means impossible but is not necessarily trivial.</t>
<t> Applications protocol designers MUST NOT assume that all attackers will be
off-path. Where possible, protocols SHOULD be designed to resist attacks from
attackers who have complete control of the network. However, designers are
expected to give more weight to attacks which can be mounted by off-path
attackers as well as on-path ones.</t>
</section>
<section anchor="linklocal" title="Link-local">
<t> One specialized case of on-path is being on the same link. In some
situations, it's desirable to distinguish between hosts who are on the local
network and those who are not. The standard technique for this is verifying
the IP TTL value <xref target="RFC0791"/>. Since the TTL must be decremented
by each forwarder, a protocol can demand that TTL be set to 255 and that all
receivers verify the TTL. A receiver then has some reason to believe that
conforming packets are from the same link. Note that this technique must be
used with care in the presence of tunneling systems, since such systems may
pass packets without decrementing TTL.</t>
</section>
</section>
</section>
<section anchor="commonissues" title="Common Issues">
<t> Although each system's security requirements are unique, certain common
requirements appear in a number of protocols. Often, when naive protocol designers
are faced with these requirements, they choose an obvious but insecure solution
even though better solutions are available. This section describes a number of
issues seen in many protocols and the common pieces of security technology that may
be useful in addressing them.</t>
<section anchor="userauth" title="User Authentication">
<t> Essentially every system which wants to control access to its resources needs
some way to authenticate users. A nearly uncountable number of such mechanisms
have been designed for this purpose. The next several sections describe some of
these techniques.</t>
<section anchor="uapass" title="Username/Password">
<t> The most common access control mechanism is simple USERNAME/PASSWORD The user
provides a username and a reusable password to the host which he wishes to use.
This system is vulnerable to a simple passive attack where the attacker sniffs
the password off the wire and then initiates a new session, presenting the
password. This threat can be mitigated by hosting the protocol over an
encrypted connection such as TLS or IPSEC. Unprotected (plaintext)
username/password systems are not acceptable in IETF standards.</t>
</section>
<section anchor="uaotp" title="Challenge Response and One Time Passwords">
<t> Systems which desire greater security than USERNAME/PASSWORD often employ
either a ONE TIME PASSWORD <xref target="RFC2289" /> scheme or a
CHALLENGE-RESPONSE. In a one time password scheme, the user is provided with a
list of passwords, which must be used in sequence, one time each. (Often these
passwords are generated from some secret key so the user can simply compute the
next password in the sequence.) SecureID and DES Gold are variants of this
scheme. In a challenge-response scheme, the host and the user share some secret
(which often is represented as a password). In order to authenticate the user,
the host presents the user with a (randomly generated) challenge. The user
computes some function based on the challenge and the secret and provides that
to the host, which verifies it. Often this computation is performed in a
handheld device, such as a DES Gold card.</t>
<t> Both types of scheme provide protection against replay attack, but often
still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of passive attack): As
previously mentioned, often the one-time password or response is computed from
a shared secret. If the attacker knows the function being used, he can simply
try all possible shared secrets until he finds one that produces the right
output. This is made easier if the shared secret is a password, in which case
he can mount a DICTIONARY ATTACK -- meaning that he tries a list of common
words (or strings) rather than just random strings.</t>
<t> These systems are also often vulnerable to an active attack. Unless
communication security is provided for the entire session, the attacker can
simply wait until authentication has been performed and hijack the connection.</t>
</section>
<section anchor="uaskey" title="Shared Keys">
<t> CHALLENGE-RESPONSE type systems can be made secure against dictionary attack
by using randomly generated shared keys instead of user-generated passwords. If
the keys are sufficiently large then keysearch attacks become impractical. This
approach works best when the keys are configured into the end nodes rather than
memorized and typed in by users, since users have trouble remembering
sufficiently long keys.</t>
<t> Like password-based systems, shared key systems suffer from management
problems. Each pair of communicating parties must have their own agreed-upon
key, which leads to there being a lot of keys.</t>
</section>
<section anchor="uakdc" title="Key Distribution Centers">
<t> One approach to solving the large number of keys problem is to use an online
"trusted third party" that mediates between the authenticating parties. The
trusted third party (generally called a a KEY DISTRIBUTION CENTER (KDC)) shares a
symmetric key or password with each party in the system. It first contacts the
KDC which gives it a TICKET containing a randomly generated symmetric key
encrypted under both peer's keys. Since only the proper peers can decrypt the
symmetric key the ticket can be used to establish a trusted association. By far
the most popular KDC system is Kerberos <xref target="RFC4120" />.</t>
</section>
<section anchor="uacert" title="Certificates">
<t> A simple approach is to have all users have CERTIFICATES <xref
target="RFC5280" /> which they then use to authenticate in some
protocol-specific way, as in TLS <xref target="RFC5246" /> or S/MIME <xref
target="RFC5751" />. A certificate is a signed credential binding an entity's
identity to its public key. The signer of a certificate is a CERTIFICATE
AUTHORITY (CA), whose certificate may itself be signed by some superior CA. In
order for this system to work, trust in one or more CAs must be established in
an out-of-band fashion. Such CAs are referred to as TRUSTED ROOTS or ROOT CAS.
The primary obstacle to this approach in client-server type systems is that it
requires clients to have certificates, which can be a deployment problem.</t>
</section>
<section anchor="uauncommon" title="Some Uncommon Systems">
<t> There are ways to do a better job than the schemes mentioned above, but they
typically don't add much security unless communications security (at least
message integrity) will be employed to secure the connection, because otherwise
the attacker can merely hijack the connection after authentication has been
performed. A number of protocols (<xref target="EKE"/>,
<xref target="SPEKE"/>, <xref target="SRP"/>) allow one to securely bootstrap a
user's password into a shared key which can be used as input to a cryptographic
protocol. One major obstacle to the deployment of these protocols has been that
their Intellectual Property status is extremely unclear. Similarly, the user
can authenticate using public key certificates (e.g., S-HTTP client
authentication). Typically these methods are used as part of a more complete
security protocol.</t>
</section>
<section anchor="uahost" title="Host Authentication">
<t> Host authentication presents a special problem. Quite commonly, the
addresses of services are presented using a DNS hostname, for instance as a
Uniform Resource Locator (URL) <xref target="RFC1738"/>. When requesting such
a service, one has to ensure that the entity that one is talking to not only
has a certificate but that that certificate corresponds to the expected
identity of the server. The important thing to have is a secure binding
between the certificate and the expected hostname.</t>
<t> For instance, it is usually not acceptable for the certificate to contain an
identity in the form of an IP address if the request was for a given hostname.
This does not provide end-to-end security because the hostname-IP mapping is
not secure unless secure name resolution (DNSSEC) is being used. This is a
particular problem when the hostname is presented at the application layer but
the authentication is performed at some lower layer.</t>
</section>
</section>
<section anchor="gsf" title="Generic Security Frameworks">
<t> Providing security functionality in a protocol can be difficult. In addition to
the problem of choosing authentication and key establishment mechanisms, one
needs to integrate it into a protocol. One response to this problem (embodied in
IPsec and TLS) is to create a lower-level security protocol and then insist that
new protocols be run over that protocol. Another approach that has recently
become popular is to design generic application layer security frameworks. The
idea is that you design a protocol that allows you to negotiate various security
mechanisms in a pluggable fashion. Application protocol designers then arrange
to carry the security protocol PDUs in their application protocol. Examples of
such frameworks include GSS-API <xref target="RFC2743"/> and SASL
<xref target="RFC4422"/>.</t>
<t> The generic framework approach has a number of problems. First, it is highly
susceptible to DOWNGRADE ATTACKS. In a downgrade attack, an active attacker
tampers with the negotiation in order to force the parties to negotiate weaker
protection than they otherwise would. It's possible to include an integrity check
after the negotiation and key establishment have both completed, but the strength
of this integrity check is necessarily limited to the weakest common algorithm.
This problem exists with any negotiation approach, but generic frameworks
exacerbate it by encouraging the application protocol author to just specify the
framework rather than think hard about the appropriate underlying mechanisms,
particularly since the mechanisms can very widely in the degree of security
offered.</t>
<t> Another problem is that it's not always obvious how the various security
features in the framework interact with the application layer protocol. For
instance, SASL can be used merely as an authentication framework -- in which case
the SASL exchange occurs but the rest of the connection is unprotected, but can
also negotiate traffic protection, such as via GSS, as a mechanism. Knowing under
what circumstances traffic protection is optional and which it is required
requires thinking about the threat model.</t>
<t> In general, authentication frameworks are most useful in situations where new
protocols are being added to systems with pre-existing legacy authentication
systems. A framework allows new installations to provide better authentication
while not forcing existing sites completely redo their legacy authentication
systems. When the security requirements of a system can be clearly identified
and only a few forms of authentication are used, choosing a single security
mechanism leads to greater simplicity and predictability. In situations where a
framework is to be used, designers SHOULD carefully examine the framework's
options and specify only the mechanisms that are appropriate for their particular
threat model. If a framework is necessary, designers SHOULD choose one of the
established ones instead of designing their own.</t>
</section>
<section anchor="nonrepu" title="Non-repudiation">
<t> The naive approach to non-repudiation is simply to use public-key digital
signatures over the content. The party who wishes to be bound (the SIGNING PARTY)
digitally signs the message in question. The counterparty (the RELYING PARTY) can
later point to the digital signature as proof that the signing party at one point
agreed to the disputed message. Unfortunately, this approach is insufficient.</t>
<t> The easiest way for the signing party to repudiate the message is by claiming
that his private key has been compromised and that some attacker (though not
necessarily the relying party) signed the disputed message. In order to defend
against this attack the relying party needs to demonstrate that the signing
party's key had not been compromised at the time of the signature. This requires
substantial infrastructure, including archival storage of certificate revocation
information and timestamp servers to establish the time that the message was
signed.</t>
<t> Additionally, the relying party might attempt to trick the signing party into
signing one message while thinking he's signing another. This problem is
particularly severe when the relying party controls the infrastructure that the
signing party uses for signing, such as in kiosk situations. In many such
situations the signing party's key is kept on a smartcard but the message to be
signed is displayed by the relying party.</t>
<t> All of these complications make non-repudiation a difficult service to deploy
in practice.</t>
</section>
<section anchor="authauth" title="Authorization vs. Authentication">
<t> AUTHORIZATION is the process by which one determines whether an authenticated
party has permission to access a particular resource or service. Although tightly
bound, it is important to realize that authentication and authorization are two
separate mechanisms. Perhaps because of this tight coupling, authentication is
sometimes mistakenly thought to imply authorization. Authentication simply
identifies a party, authorization defines whether they can perform a certain
action.</t>
<t> Authorization necessarily relies on authentication, but authentication alone
does not imply authorization. Rather, before granting permission to perform an
action, the authorization mechanism must be consulted to determine whether that
action is permitted.</t>
<section anchor="acl" title="Access Control Lists">
<t> One common form of authorization mechanism is an access control list (ACL),
which lists users that are permitted access to a resource. Since assigning
individual authorization permissions to each resource is tedious, resources are
often hierarchically arranged so that the parent resource's ACL is inherited by
child resources. This allows administrators to set top level policies and
override them when necessary.</t>
</section>
<section anchor="certs" title="Certificate Based Systems">
<t> While the distinction between authentication and authorization is intuitive
when using simple authentication mechanisms such as username and password
(i.e., everyone understands the difference between the administrator account
and a user account), with more complex authentication mechanisms the
distinction is sometimes lost.</t>
<t> With certificates, for instance, presenting a valid signature does not imply
authorization. The signature must be backed by a certificate chain that
contains a trusted root, and that root must be trusted in the given context.
For instance, users who possess certificates issued by the Acme MIS CA may have
different web access privileges than users who possess certificates issued by
the Acme Accounting CA, even though both of these CAs are "trusted" by the Acme
web server.</t>
<t> Mechanisms for enforcing these more complicated properties have not yet been
completely explored. One approach is simply to attach policies to ACLs
describing what sorts of certificates are trusted. Another approach is to carry
that information with the certificate, either as a certificate
extension/attribute (PKIX <xref target="RFC5280"/>, SPKI <xref
target="RFC2693"/>) or as a separate "Attribute Certificate".</t>
</section>
</section>
<section anchor="trafficsec" title="Providing Traffic Security">
<t> Securely designed protocols should provide some mechanism for securing (meaning
integrity protecting, authenticating, and possibly encrypting) all sensitive
traffic. One approach is to secure the protocol itself, as in DNSSEC <xref
target="RFC4033"/>, S/MIME <xref target="RFC5751"/> or S-HTTP <xref
target="RFC2660"/>. Although this provides security which is most fitted to the
protocol, it also requires considerable effort to get right.</t>
<t> Many protocols can be adequately secured using one of the available channel
security systems. We'll discuss the two most common, IPsec <xref
target="RFC4302"/><xref target="RFC4303"/> and TLS <xref target="RFC5246"/>.</t>
<section anchor="ipsec" title="IPsec">
<t> The IPsec protocols (specifically, AH and ESP) can provide transmission
security for all traffic between two hosts. The IPsec protocols support varying
granularities of user identification, including for example "IP Subnet",
"IP Address", "Fully Qualified Domain Name", and individual user
("Mailbox name"). These varying levels of identification are employed as inputs
to access control facilities that are an intrinsic part of IPsec. However, a
given IPsec implementation might not support all identity types. In particular,
security gateways may not provide user-to-user authentication or have
mechanisms to provide that authentication information to applications.</t>
<t> When AH or ESP is used, the application programmer might not need to do
anything (if AH or ESP has been enabled system-wide) or might need to make
specific software changes (e.g., adding specific setsockopt() calls) --
depending on the AH or ESP implementation being used. Unfortunately, APIs for
controlling IPsec implementations are not yet standardized.</t>
<t> The primary obstacle to using IPsec to secure other protocols is deployment.
The major use of IPsec at present is for VPN applications, especially for
remote network access. Without extremely tight coordination between security
administrators and application developers, VPN usage is not well suited to
providing security services for individual applications since it is difficult
for such applications to determine what security services have in fact been
provided.</t>
<t> IPsec deployment in host-to-host environments has been slow. Unlike
application security systems such as TLS, adding IPsec to a non-IPsec system
generally involves changing the operating system, either by modifying with the
kernel or installing new drivers. This is a substantially greater undertaking
than simply installing a new application. However, recent versions of a number
of commodity operating systems include IPsec stacks, so deployment is becoming
easier.</t>
<t> In environments where IPsec is sure to be available, it represents a viable
option for protecting application communications traffic. If the traffic to be
protected is UDP, IPsec and application-specific object security are the only
options. However, designers MUST NOT assume that IPsec will be available. A
security policy for a generic application layer protocol SHOULD NOT simply
state that IPsec must be used, unless there is some reason to believe that
IPsec will be available in the intended deployment environment. In environments
where IPsec may not be available and the traffic is solely TCP, TLS is the
method of choice, since the application developer can easily ensure its
presence by including a TLS implementation in his package.</t>
<t> In the special-case of IPv6, both AH and ESP are mandatory to implement.
Hence, it is reasonable to assume that AH/ESP are already available for
IPv6-only protocols or IPv6-only deployments. However, automatic key management
(IKE) is not required to implement so protocol designers should not assume it
will be present. <xref target="RFC5406"/> provides quite a bit of guidance on
when IPsec is a good choice.</t>
</section>
<section anchor="ssl" title="SSL/TLS">
<t> Currently, the most common approach is to use SSL or its successor TLS. They
provide channel security for a TCP connection at the application level. That
is, they run over TCP. SSL implementations typically provide a Berkeley
Sockets-like interface for easy programming. The primary issue when designing
a protocol solution around TLS is to differentiate between connections
protected using TLS and those which are not.</t>
<t> The two primary approaches used have a separate well-known port for TLS
connections (e.g., the HTTP over TLS port is 443) <xref target="RFC2818"/> or
to have a mechanism for negotiating upward from the base protocol to TLS as in
UPGRADE <xref target="RFC2817"/> or STARTTLS <xref target="RFC3207"/>. When an
upward negotiation strategy is used, care must be taken to ensure that an
attacker can not force a clear connection when both parties wish to use TLS.</t>
<t> Note that TLS depends upon a reliable protocol such as TCP or SCTP. This
produces two notable difficulties. First, it cannot be used to secure datagram
protocols that use UDP. Second, TLS is susceptible to IP layer attacks that
IPsec is not. Typically, these attacks take some form of denial of service or
connection assassination. For instance, an attacker might forge a TCP RST to
shut down SSL connections. TLS has mechanisms to detect truncation attacks but
these merely allow the victim to know he is being attacked and do not provide
connection survivability in the face of such attacks. By contrast, if IPsec
were being used, such a forged RST could be rejected without affecting the TCP
connection. If forged RSTs or other such attacks on the TCP connection are a
concern, then AH/ESP or the TCP Authentication Option (TCP-AO) <xref
target="RFC5925"/> are the preferred choices.</t>
<section anchor="sslvh" title="Virtual Hosts">
<t> If the "separate ports" approach to TLS is used, then TLS will be
negotiated before any application-layer traffic is sent. This can cause a
problem with protocols that use virtual hosts, such as HTTP <xref
target="RFC7230"/>, since the server does not know which certificate to offer
the client during the TLS handshake. The TLS hostname extension <xref
target="RFC5246"/> can be used to solve this problem, although it is too new
to have seen wide deployment.</t>
</section>
<section anchor="sslremoteauth" title="Remote Authentication and TLS">
<t> One difficulty with using TLS is that the server is authenticated via a
certificate. This can be inconvenient in environments where previously the
only form of authentication was a password shared between client and server.
It's tempting to use TLS without an authenticated server (i.e., with
anonymous DH or a self-signed RSA certificate) and then authenticate via some
challenge-response mechanism such as SASL with CRAM-MD5.</t>
<t> Unfortunately, this composition of SASL and TLS is less strong than one
would expect. It's easy for an active attacker to hijack this connection.
The client man-in-the-middles the SSL connection (remember we're not
authenticating the server, which is what ordinarily prevents this attack) and
then simply proxies the SASL handshake. From then on, it's as if the
connection were in the clear, at least as far as that attacker is concerned.
In order to prevent this attack, the client needs to verify the server's
certificate.</t>
<t> However, if the server is authenticated, challenge-response becomes less
desirable. If you already have a hardened channel then simple passwords are
fine. In fact, they're arguably superior to challenge-response since they do
not require that the password be stored in the clear on the server. Thus,
compromise of the key file with challenge-response systems is more serious
than if simple passwords were used.</t>
<t> Note that if the client has a certificate than SSL-based client
authentication can be used. To make this easier, SASL provides the EXTERNAL
mechanism, whereby the SASL client can tell the server "examine the outer
channel for my identity". Obviously, this is not subject to the layering
attacks described above.</t>
</section>
</section>
<section anchor="ssh" title="Remote Login">
<t> In some special cases it may be worth providing channel-level security
directly in the application rather than using IPSEC or SSL/TLS. One such case
is remote terminal security. Characters are typically delivered from client to
server one character at a time. Since SSL/TLS and AH/ESP authenticate and
encrypt every packet, this can mean a data expansion of 20-fold. The telnet
encryption option <xref target="RFC2946"/> prevents this expansion by foregoing
message integrity.</t>
<t> When using remote terminal service, it's often desirable to securely perform
other sorts of communications services. In addition to providing remote login,
SSH <xref target="RFC4253"/> also provides secure port forwarding for arbitrary
TCP ports, thus allowing users run arbitrary TCP-based applications over the
SSH channel. Note that SSH Port Forwarding can be security issue if it is used
improperly to circumvent firewall and improperly expose insecure internal
applications to the outside world.</t>
</section>
</section>
<section anchor="antidos" title="Denial of Service Attacks and Countermeasures">
<t> Denial of service attacks are all too frequently viewed as an fact of life.
One problem is that an attacker can often choose from one of many denial of service
attacks to inflict upon a victim, and because most of these attacks cannot be
thwarted, common wisdom frequently assumes that there is no point protecting
against one kind of denial of service attack when there are many other denial of
service attacks that are possible but that cannot be prevented.</t>
<t> However, not all denial of service attacks are equal and more importantly, it is
possible to design protocols so that denial of service attacks are made more
difficult, if not impractical. Recent SYN flood attacks <xref target="TCPSYN"/>
demonstrate both of these properties: SYN flood attacks are so easy, anonymous, and
effective that they are more attractive to attackers than other attacks; and
because the design of TCP enables this attack.</t>
<t> Because complete DoS protection is so difficult, security against DoS must be
dealt with pragmatically. In particular, some attacks which would be desirable to
defend against cannot be defended against economically. The goal should be to
manage risk by defending against attacks with sufficiently high ratios of severity
to cost of defense. Both severity of attack and cost of defense change as
technology changes and therefore so does the set of attacks which should be
defended against.</t>
<t> Authors of internet standards MUST describe which denial of service attacks their
protocol is susceptible to. This description MUST include the reasons it was either
unreasonable or out of scope to attempt to avoid these denial of service attacks.</t>
<section anchor="dosblind" title="Blind Denial of Service">
<t> BLIND denial of service attacks are particularly pernicious. With a blind
attack the attacker has a significant advantage. If the attacker must be able
to receive traffic from the victim, then he must either subvert the routing
fabric or use his own IP address. Either provides an opportunity for the victim
to track the attacker and/or filter out his traffic. With a blind attack the
attacker can use forged IP addresses, making it extremely difficult for the
victim to filter out his packets. The TCP SYN flood attack is an example of a
blind attack. Designers should make every attempt possible to prevent blind
denial of service attacks.</t>
</section>
<section anchor="dosddos" title="Distributed Denial of Service">
<t> Even more dangerous are DISTRIBUTED denial of service attacks (DDoS) <xref
target="DDOS"/>. In a DDoS the attacker arranges for a number of machines to
attack the target machine simultaneously. Usually this is accomplished by
infecting a large number of machines with a program that allows remote
initiation of attacks. The machines actually performing the attack are called
ZOMBIEs and are likely owned by unsuspecting third parties in an entirely
different location from the true attacker. DDoS attacks can be very hard to
counter because the zombies often appear to be making legitimate protocol
requests and simply crowd out the real users. DDoS attacks can be difficult to
thwart, but protocol designers are expected to be cognizant of these forms of
attack while designing protocols.</t>
</section>
<section anchor="dosavoid" title="Avoiding Denial of Service">
<t> There are two common approaches to making denial of service attacks more
difficult:</t>
<section anchor="puzzle" title="Make your attacker do more work than you do">
<t> If an attacker consumes more of his resources than yours when launching an
attack, attackers with fewer resources than you will be unable to launch
effective attacks. One common technique is to require the attacker perform a
time-intensive operation, such as a cryptographic operation. Note that an
attacker can still mount a denial of service attack if he can muster
substantially sufficient CPU power. For instance, this technique would not
stop the distributed attacks described in <xref target="TCPSYN"/>.</t>
</section>
<section anchor="ret_rout" title="Make your attacker prove they can receive data from you">
<t> A blind attack can be subverted by forcing the attacker to prove that they
can can receive data from the victim. A common technique is to require that
the attacker reply using information that was gained earlier in the message
exchange. If this countermeasure is used, the attacker must either use his
own address (making him easy to track) or to forge an address which will be
routed back along a path that traverses the host from which the attack is
being launched.</t>
<t> Hosts on small subnets are thus useless to the attacker (at least in the
context of a spoofing attack) because the attack can be traced back to a
subnet (which should be sufficient for locating the attacker) so that
anti-attack measures can be put into place (for instance, a boundary router
can be configured to drop all traffic from that subnet). A common technique
is to require that the attacker reply using information that was gained
earlier in the message exchange.</t>
</section>
</section>
<section anchor="dossynflood" title="Example: TCP SYN Floods">
<t> TCP/IP is vulnerable to SYN flood attacks (which are described in <xref
target="insertion"/>) because of the design of the 3-way handshake. First, an
attacker can force a victim to consume significant resources (in this case,
memory) by sending a single packet. Second, because the attacker can perform
this action without ever having received data from the victim, the attack can
be performed anonymously (and therefore using a large number of forged source
addresses).</t>
</section>
<section anchor="dosphoturis" title="Example: Photuris">
<t> Photuris <xref target="RFC2522"/> specifies an anti-clogging mechanism that
prevents attacks on Photuris that resemble the SYN flood attack. Photuris
employs a time-variant secret to generate a "cookie" which is returned to the
attacker. This cookie must be returned in subsequent messages for the exchange
to progress. The interesting feature is that this cookie can be regenerated by
the victim later in the exchange, and thus no state need be retained by the
victim until after the attacker has proven that he can receive packets from the
victim.</t>
</section>
</section>
<section anchor="objsec" title="Object vs. Channel Security">
<t> It's useful to make the conceptual distinction between object security and
channel security. Object security refers to security measures which apply to
entire data objects. Channel security measures provide a secure channel over
which objects may be carried transparently but the channel has no special
knowledge about object boundaries.</t>
<t> Consider the case of an email message. When it's carried over an IPSEC or TLS
secured connection, the message is protected during transmission. However, it is
unprotected in the receiver's mailbox, and in intermediate spool files along the
way. Moreover, since mail servers generally run as a daemon, not a user,
authentication of messages generally merely means authentication of the daemon
not the user. Finally, since mail transport is hop-by-hop, even if the user
authenticates to the first hop relay the authentication can't be safely verified
by the receiver.</t>
<t> By contrast, when an email message is protected with S/MIME or OpenPGP, the
entire message is encrypted and integrity protected until it is examined and
decrypted by the recipient. It also provides strong authentication of the actual
sender, as opposed to the machine the message came from. This is object security.
Moreover, the receiver can prove the signed message's authenticity to a third
party.</t>
<t> Note that the difference between object and channel security is a matter of
perspective. Object security at one layer of the protocol stack often looks like
channel security at the next layer up. So, from the perspective of the IP layer,
each packet looks like an individually secured object. But from the perspective
of a web client, IPSEC just provides a secure channel.</t>
<t> The distinction isn't always clear-cut. For example, S-HTTP provides object
level security for a single HTTP transaction, but a web page typically consists
of multiple HTTP transactions (the base page and numerous inline images). Thus,
from the perspective of the total web page, this looks rather more like channel
security. Object security for a web page would consist of security for the
transitive closure of the page and all its embedded content as a single unit.</t>
</section>
<section anchor="fw1" title="Firewalls">
<t> It's common security practice in modern networks to partition the network into
external and internal networks using a firewall. The internal network is then
assumed to be secure and only limited security measures are used there. The
internal portion of such a network is often called a WALLED GARDEN.</t>
<t> Internet protocol designers cannot safely assume that their protocols will be
deployed in such an environment, for three reasons. First, protocols which were
originally designed to be deployed in closed environments often are later
deployed on the Internet, thus creating serious vulnerabilities.</t>
<t> Second, networks which appear to be topologically disconnected may not be. One
reason may be that the network has been reconfigured to allow access by the
outside world. Moreover, firewalls are increasingly passing generic application
layer protocols such as <xref target="SOAP"/> or HTTP. Network protocols which
are based on these generic protocols cannot in general assume that a firewall
will protect them. Finally, one of the most serious security threats to systems
is from insiders, not outsiders. Since insiders by definition have access to the
internal network, topological protections such as firewalls will not protect
them.</t>
</section>
</section>
<section anchor="writing" title="Writing Security Considerations Sections">
<t> While it is not a requirement that any given protocol or system be immune to all
forms of attack, it is still necessary for authors to consider as many forms as
possible. Part of the purpose of the Security Considerations section is to explain
what attacks are out of scope and what countermeasures can be applied to defend
against them.</t>
<t> There should be a clear description of the kinds of threats on the described
protocol or technology. This should be approached as an effort to perform "due
diligence" in describing all known or foreseeable risks and threats to potential
implementers and users.</t>
<t> Authors MUST describe<list style="numbers">
<t> which attacks are out of scope (and why!)</t>
<t> which attacks are in-scope<list style="format 2.%d.">
<t> and the protocol is susceptible to</t>
<t> and the protocol protects against</t></list></t></list></t>
<t> At least the following forms of attack MUST be considered: eavesdropping, replay,
message insertion, deletion, modification, and man-in-the-middle. Potential denial
of service attacks MUST be identified as well. If the protocol incorporates
cryptographic protection mechanisms, it should be clearly indicated which portions
of the data are protected and what the protections are (i.e., integrity only,
confidentiality, and/or endpoint authentication, etc.). Some indication should
also be given to what sorts of attacks the cryptographic protection is susceptible.
Data which should be held secret (keying material, random seeds, etc.) should be
clearly labeled.</t>
<t> If the technology involves authentication, particularly user-host authentication,
the security of the authentication method MUST be clearly specified. That is,
authors MUST document the assumptions that the security of this authentication
method is predicated upon. For instance, in the case of the UNIX username/password
login method, a statement to the effect of:<list>
<t> Authentication in the system is secure only to the extent that it is difficult
to guess or obtain a ASCII password that is a maximum of 8 characters long. These
passwords can be obtained by sniffing telnet sessions or by running the 'crack'
program using the contents of the /etc/passwd file. Attempts to protect against
on-line password guessing by (1) disconnecting after several unsuccessful login
attempts and (2) waiting between successive password prompts is effective only to
the extent that attackers are impatient.</t>
<t> Because the /etc/passwd file maps usernames to user ids, groups, etc. it must
be world readable. In order to permit this usage but make running crack more
difficult, the file is often split into /etc/passwd and a 'shadow' password file.
The shadow file is not world readable and contains the encrypted password. The
regular /etc/passwd file contains a dummy password in its place.</t></list></t>
<t> It is insufficient to simply state that one's protocol should be run over some
lower layer security protocol. If a system relies upon lower layer security
services for security, the protections those services are expected to provide MUST
be clearly specified. In addition, the resultant properties of the combined system
need to be specified.</t>
<t> Note: In general, the IESG will not approve standards track protocols which do
not provide for strong authentication, either internal to the protocol or through
tight binding to a lower layer security protocol.</t>
<t> The threat environment addressed by the Security Considerations section MUST at
a minimum include deployment across the global Internet across multiple
administrative boundaries without assuming that firewalls are in place, even if
only to provide justification for why such consideration is out of scope for the
protocol. It is not acceptable to only discuss threats applicable to LANs and
ignore the broader threat environment. All IETF standards-track protocols are
considered likely to have deployment in the global Internet. In some cases, there
might be an Applicability Statement discouraging use of a technology or protocol in
a particular environment. Nonetheless, the security issues of broader deployment
should be discussed in the document.</t>
<t> There should be a clear description of the residual risk to the user or operator
of that protocol after threat mitigation has been deployed. Such risks might arise
from compromise in a related protocol (e.g., IPsec is useless if key management has
been compromised), from incorrect implementation, compromise of the security
technology used for risk reduction (e.g., a cipher with a 40-bit key), or there
might be risks that are not addressed by the protocol specification (e.g., denial
of service attacks on an underlying link protocol). Particular care should be
taken in situations where the compromise of a single system would compromise an
entire protocol. For instance, in general protocol designers assume that
end-systems are inviolate and don't worry about physical attack. However, in cases
(such as a certificate authority) where compromise of a single system could lead to
widespread compromises, it is appropriate to consider systems and physical security
as well.</t>
<t> There should also be some discussion of potential security risks arising from
potential misapplications of the protocol or technology described in the RFC. This
might be coupled with an Applicability Statement for that RFC.</t>
</section>
<section anchor="examples" title="Examples">
<t> This section consists of some example security considerations sections, intended
to give the reader a flavor of what's intended by this document.</t>
<t> The first example is a 'retrospective' example, applying the criteria of this
document to an existing widely deployed protocol, SMTP. The second example is a
good security considerations section clipped from a current protocol.</t>
<section anchor="smtp" title="SMTP">
<t> When RFC 821 was written, Security Considerations sections were not required in
RFCs, and none is contained in that document. <xref target="RFC5231"/> updated
RFC 821 and added a detailed security considerations section. We reproduce here
the Security Considerations section from that document (with new section
numbers). Our comments are indented and prefaced with 'NOTE:'. We also add a
number of new sections to cover topics we consider important. Those sections are
marked with (NEW) in the section header.</t>
<section anchor="smtp_sec_cons" title="Security Considerations">
<section anchor="ssc_1" title="Mail Security and Spoofing">
<t> SMTP mail is inherently insecure in that it is feasible for even fairly
casual users to negotiate directly with receiving and relaying SMTP servers
and create messages that will trick a naive recipient into believing that
they came from somewhere else. Constructing such a message so that the
"spoofed" behavior cannot be detected by an expert is somewhat more
difficult, but not sufficiently so as to be a deterrent to someone who is
determined and knowledgeable. Consequently, as knowledge of Internet mail
increases, so does the knowledge that SMTP mail inherently cannot be
authenticated, or integrity checks provided, at the transport level. Real
mail security lies only in end-to-end methods involving the message bodies,
such as those which use digital signatures (see e.g., <xref
target="scs_3"/>).<list>
<t> NOTE: One bad approach to sender authentication is IDENT <xref
target="RFC1414"/> in which the receiving mail server contacts the alleged
sender and asks for the username of the sender. This is a bad idea for a
number of reasons, including but not limited to relaying, TCP connection
hijacking, and simple lying by the origin server. Aside from the fact that
IDENT is of low security value, use of IDENT by receiving sites can lead to
operational problems. Many sending sites blackhole IDENT requests, thus
causing mail to be held until the receiving server's IDENT request times
out.</t></list></t>
<t> Various protocol extensions and configuration options that provide
authentication at the transport level (e.g., from an SMTP client to an SMTP
server) improve somewhat on the traditional situation described above.
However, unless they are accompanied by careful handoffs of responsibility in
a carefully-designed trust environment, they remain inherently weaker than
end-to-end mechanisms which use digitally signed messages rather than
depending on the integrity of the transport system.</t>
<t> Efforts to make it more difficult for users to set envelope return path and
header "From" fields to point to valid addresses other than their own are
largely misguided: they frustrate legitimate applications in which mail is
sent by one user on behalf of another or in which error (or normal) replies
should be directed to a special address. (Systems that provide convenient
ways for users to alter these fields on a per-message basis should attempt to
establish a primary and permanent mailbox address for the user so that Sender
fields within the message data can be generated sensibly.)</t>
<t> This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality not be
disabled in the hope of providing some small margin of protection against an
ignorant user who is trying to fake mail.<list>
<t> NOTE: We have added additional material on communications security and
SMTP in <xref target="smtp_comsec"/> In a final specification, the above
text would be edited somewhat to reflect that fact.</t></list></t>
</section>
<section anchor="ssc_2" title="Blind Copies">
<t> Addresses that do not appear in the message headers may appear in the RCPT
commands to an SMTP server for a number of reasons. The two most common
involve the use of a mailing address as a "list exploder" (a single address
that resolves into multiple addresses) and the appearance of "blind copies".
Especially when more than one RCPT command is present, and in order to avoid
defeating some of the purpose of these mechanisms, SMTP clients and servers
SHOULD NOT copy the full set of RCPT command arguments into the headers,
either as part of trace headers or as informational or private-extension
headers. Since this rule is often violated in practice, and cannot be
enforced, sending SMTP systems that are aware of "bcc" use MAY find it
helpful to send each blind copy as a separate message transaction containing
only a single RCPT command.</t>
<t> There is no inherent relationship between either "reverse" (from MAIL,
SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction
("envelope") and the addresses in the headers. Receiving systems SHOULD NOT
attempt to deduce such relationships and use them to alter the headers of the
message for delivery. The popular "Apparently-to" header is a violation of
this principle as well as a common source of unintended information
disclosure and SHOULD NOT be used.</t>
</section>
<section anchor="ssc_3" title="VRFY, EXPN, and Security">
<t> As discussed in <xref target="offpath"/>, individual sites may want to
disable either or both of VRFY or EXPN for security reasons. As a corollary
to the above, implementations that permit this MUST NOT appear to have
verified addresses that are not, in fact, verified. If a site disables these
commands for security reasons, the SMTP server MUST return a 252 response,
rather than a code that could be confused with successful or unsuccessful
verification.</t>
<t> Returning a 250 reply code with the address listed in the VRFY command
after having checked it only for syntax violates this rule. Of course, an
implementation that "supports" VRFY by always returning 550 whether or not
the address is valid is equally not in conformance.</t>
<t> Within the last few years, the contents of mailing lists have become
popular as an address information source for so-called "spammers." The use of
EXPN to "harvest" addresses has increased as list administrators have
installed protections against inappropriate uses of the lists themselves.
Implementations SHOULD still provide support for EXPN, but sites SHOULD
carefully evaluate the tradeoffs. As authentication mechanisms are introduced
into SMTP, some sites may choose to make EXPN available only to authenticated
requesters.<list>
<t> NOTE: It's not clear that disabling VRFY adds much protection, since it's
often possible to discover whether an address is valid using RCPT TO.</t></list></t>
</section>
<section anchor="ssc_4" title="Information Disclosure in Announcements">
<t> There has been an ongoing debate about the tradeoffs between the debugging
advantages of announcing server type and version (and, sometimes, even server
domain name) in the greeting response or in response to the HELP command and
the disadvantages of exposing information that might be useful in a potential
hostile attack. The utility of the debugging information is beyond doubt.
Those who argue for making it available point out that it is far better to
actually secure an SMTP server rather than hope that trying to conceal known
vulnerabilities by hiding the server's precise identity will provide more
protection. Sites are encouraged to evaluate the tradeoff with that issue in
mind; implementations are strongly encouraged to minimally provide for making
type and version information available in some way to other network hosts.</t>
</section>
<section anchor="ssc_5" title="Information Disclosure in Trace Fields">
<t> In some circumstances, such as when mail originates from within a LAN whose
hosts are not directly on the public Internet, trace ("Received") fields
produced in conformance with this specification may disclose host names and
similar information that would not normally be available. This ordinarily
does not pose a problem, but sites with special concerns about name
disclosure should be aware of it. Also, the optional FOR clause should be
supplied with caution or not at all when multiple recipients are involved
lest it inadvertently disclose the identities of "blind copy" recipients to
others.</t>
</section>
<section anchor="ssc_6" title="Information Disclosure in Message Forwarding">
<t> As discussed in <xref target="topo"/>, use of the 251 or 551 reply codes to
identify the replacement address associated with a mailbox may inadvertently
disclose sensitive information. Sites that are concerned about those issues
should ensure that they select and configure servers appropriately.</t>
</section>
<section anchor="ssc_7" title="Scope of Operation of SMTP Servers">
<t> It is a well-established principle that an SMTP server may refuse to accept
mail for any operational or technical reason that makes sense to the site
providing the server. However, cooperation among sites and installations
makes the Internet possible. If sites take excessive advantage of the right
to reject traffic, the ubiquity of email availability (one of the strengths
of the Internet) will be threatened; considerable care should be taken and
balance maintained if a site decides to be selective about the traffic it
will accept and process.</t>
<t> In recent years, use of the relay function through arbitrary sites has been
used as part of hostile efforts to hide the actual origins of mail. Some
sites have decided to limit the use of the relay function to known or
identifiable sources, and implementations SHOULD provide the capability to
perform this type of filtering. When mail is rejected for these or other
policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT
as appropriate.</t>
</section>
<section anchor="ssc_8" title="Inappropriate Usage (NEW)">
<t> SMTP itself provides no protection is provided against unsolicited
commercial mass e-mail (aka spam). It is extremely difficult to tell a priori
whether a given message is spam or not. From a protocol perspective, spam is
indistinguishable from other e-mail -- the distinction is almost entirely
social and often quite subtle. (For instance, is a message from a merchant
from whom you've purchased items before advertising similar items spam?) SMTP
spam-suppression mechanisms are generally limited to identifying known spam
senders and either refusing to service them or target them for
punishment/disconnection. <xref target="RFC2505"/> provides extensive
guidance on making SMTP servers spam-resistant. We provide a brief
discussion of the topic here.</t>
<t> The primary tool for refusal to service spammers is the blacklist. Some
authority such as Mail Abuse Protection System (MAPS) collects and publishes
a list of known spammers. Individual SMTP servers then block the blacklisted
offenders (generally by IP address).</t>
<t> In order to avoid being blacklisted or otherwise identified, spammers often
attempt to obscure their identity, either simply by sending a false SMTP
identity or by forwarding their mail through an Open Relay -- an SMTP server
which will perform mail relaying for any sender. As a consequence, there are
now blacklists such as Open Relay Blocking System (ORBS) of open relays as
well.</t>
<section anchor="ssc_8_1" title="Closed Relaying (NEW)">
<t> To avoid being used for spam forwarding, many SMTP servers operate as
closed relays, providing relaying service only for clients who they can
identify. Such relays should generally insist that senders advertise a
sending address consistent with their known identity. If the relay is
providing service for an identifiable network (such as a corporate network
or an ISP's network) then it is sufficient to block all other IP
addresses). In other cases, explicit authentication must be used. The two
standard choices for this are TLS through STARTTLS <xref target="RFC3207"/>
and SASL <xref target="RFC4954"/>.</t>
</section>
<section anchor="ssc_8_2" title="Endpoints (NEW)">
<t> Realistically, SMTP endpoints cannot refuse to deny service to
unauthenticated senders. Since the vast majority of senders are
unauthenticated, this would break Internet mail interoperability. The
exception to this is when the endpoint server should only be receiving mail
from some other server which can itself receive unauthenticated messages.
For instance, a company might operate a public gateway but configure its
internal servers to only talk to the gateway.</t>
</section>
</section>
</section>
<section anchor="smtp_comsec" title="Communications security issues (NEW)">
<t> SMTP itself provides no communications security, and therefore a large number
of attacks are possible. A passive attack is sufficient to recover the text of
messages transmitted with SMTP. No endpoint authentication is provided by the
protocol. Sender spoofing is trivial, and therefore forging email messages is
trivial. Some implementations do add header lines with hostnames derived
through reverse name resolution (which is only secure to the extent that it is
difficult to spoof DNS -- not very), although these header lines are normally
not displayed to users. Receiver spoofing is also fairly straight-forward,
either using TCP connection hijacking or DNS spoofing. Moreover, since email
messages often pass through SMTP gateways, all intermediate gateways must be
trusted, a condition nearly impossible on the global Internet.</t>
<t> Several approaches are available for alleviating these threats. In order of
increasingly high level in the protocol stack, we have:<list style="symbols">
<t> SMTP over IPSEC</t>
<t> SMTP/TLS</t>
<t> S/MIME and PGP/MIME</t></list></t>
<section anchor="scs_1" title="SMTP over IPSEC (NEW)">
<t> An SMTP connection run over IPSEC can provide confidentiality for the
message between the sender and the first hop SMTP gateway, or between any
pair of connected SMTP gateways. That is to say, it provides channel security
for the SMTP connections. In a situation where the message goes directly from
the client to the receiver's gateway, this may provide substantial security
(though the receiver must still trust the gateway). Protection is provided
against replay attacks, since the data itself is protected and the packets
cannot be replayed.</t>
<t> Endpoint identification is a problem, however, unless the receiver's
address can be directly cryptographically authenticated. Sender
identification is not generally available, since generally only the sender's
machine is authenticated, not the sender himself. Furthermore, the identity
of the sender simply appears in the From header of the message, so it is
easily spoofable by the sender. Finally, unless the security policy is set
extremely strictly, there is also an active downgrade to cleartext attack.</t>
<t> Another problem with IPsec as a security solution for SMTP is the lack of a
standard IPsec API. In order to take advantage of IPsec, applications in
general need to be able to instruct the IPsec implementation about their
security policies and discover what protection has been applied to their
connections. Without a standard API this is very difficult to do portably.</t>
<t> Implementors of SMTP servers or SMTP administrators MUST NOT assume that
IPsec will be available unless they have reason to believe that it will be
(such as the existence of preexisting association between two machines).
However, it may be a reasonable procedure to attempt to create an IPsec
association opportunistically to a peer server when mail is delivered. Note
that in cases where IPsec is used to provide a VPN tunnel between two sites,
this is of substantial security value, particularly to the extent that
confidentiality is provided, subject to the caveats mentioned above. Also
see USEIPSEC <xref target="RFC5406"/> for general guidance on the
applicability of IPsec.</t>
</section>
<section anchor="scs_2" title="SMTP/TLS (NEW)">
<t> SMTP can be combined with TLS as described in STARTTLS <xref
target="RFC3207"/>. This provides similar protection to that provided when
using IPsec. Since TLS certificates typically contain the server's host name,
recipient authentication may be slightly more obvious, but is still
susceptible to DNS spoofing attacks. Notably, common implementations of TLS
contain a US exportable (and hence low security) mode. Applications desiring
high security should ensure that this mode is disabled. Protection is
provided against replay attacks, since the data itself is protected and the
packets cannot be replayed. [Note: The Security Considerations section of
the SMTP over TLS document is quite good and bears reading as an example of
how to do things.]</t>
</section>
<section anchor="scs_3" title="S/MIME and PGP/MIME (NEW)">
<t> S/MIME and PGP/MIME are both message oriented security protocols. They
provide object security for individual messages. With various settings,
sender and recipient authentication and confidentiality may be provided. More
importantly, the identification is not of the sending and receiving machines,
but rather of the sender and recipient themselves. (Or, at least, of
cryptographic keys corresponding to the sender and recipient.) Consequently,
end-to-end security may be obtained. Note, however, that no protection is
provided against replay attacks. Note also that S/MIME and PGP/MIME generally
provide identifying marks for both sender and receiver. Thus even when
confidentiality is provided, traffic analysis is still possible.</t>
</section>
</section>
<section anchor="smtp_dos" title="Denial of Service (NEW)">
<t> None of these security measures provides any real protection against denial
of service. SMTP connections can easily be used to tie up system resources in
a number of ways, including excessive port consumption, excessive disk usage
(email is typically delivered to disk files), and excessive memory consumption
(sendmail, for instance, is fairly large, and typically forks a new process to
deal with each message.)</t>
<t> If transport- or application-layer security is used for SMTP connections, it
is possible to mount a variety of attacks on individual connections using
forged RSTs or other kinds of packet injection.</t>
</section>
</section>
<section anchor="vrrp" title="VRRP">
<t> The second example is from VRRP, the Virtual Router Redundance Protocol
<xref target="RFC5798"/>. We reproduce here the Security Considerations section
from that document (with new section numbers). Our comments are indented and
prefaced with 'NOTE:'.</t>
<section anchor="vrrp_sec_cons" title="Security Considerations">
<t> VRRP is designed for a range of internetworking environments that may employ
different security policies. The protocol includes several authentication
methods ranging from no authentication, simple clear text passwords, and strong
authentication using IP Authentication with MD5 HMAC. The details on each
approach including possible attacks and recommended environments follows.</t>
<t> Independent of any authentication type VRRP includes a mechanism (setting
TTL=255, checking on receipt) that protects against VRRP packets being injected
from another remote network. This limits most vulnerabilities to local
attacks.<list>
<t> NOTE: The security measures discussed in the following sections only
provide various kinds of authentication. No confidentiality is provided at
all. This should be explicitly described as outside the scope.</t></list></t>
<section anchor="vsc_1" title="No Authentication">
<t> The use of this authentication type means that VRRP protocol exchanges are
not authenticated. This type of authentication SHOULD only be used in
environments were there is minimal security risk and little chance for
configuration errors (e.g., two VRRP routers on a LAN).</t>
</section>
<section anchor="vsc_2" title="Simple Text Password">
<t> The use of this authentication type means that VRRP protocol exchanges are
authenticated by a simple clear text password.</t>
<t> This type of authentication is useful to protect against accidental
misconfiguration of routers on a LAN. It protects against routers
inadvertently backing up another router. A new router must first be
configured with the correct password before it can run VRRP with another
router. This type of authentication does not protect against hostile attacks
where the password can be learned by a node snooping VRRP packets on the LAN.
The Simple Text Authentication combined with the TTL check makes it difficult
for a VRRP packet to be sent from another LAN to disrupt VRRP operation.</t>
<t> This type of authentication is RECOMMENDED when there is minimal risk of
nodes on a LAN actively disrupting VRRP operation. If this type of
authentication is used the user should be aware that this clear text password
is sent frequently, and therefore should not be the same as any security
significant password.<list>
<t> NOTE: This section should be clearer. The basic point is that no
authentication and Simple Text are only useful for a very limited threat
model, namely that none of the nodes on the local LAN are hostile. The TTL
check prevents hostile nodes off-LAN from posing as valid nodes, but
nothing stops hostile nodes on-LAN from impersonating authorized nodes.
This is not a particularly realistic threat model in many situations. In
particular, it's extremely brittle: the compromise of any node the LAN
allows reconfiguration of the VRRP nodes.</t></list></t>
</section>
<section anchor="vsc_3" title="IP Authentication Header">
<t> The use of this authentication type means the VRRP protocol exchanges are
authenticated using the mechanisms defined by the IP Authentication Header
<xref target="RFC4302"/> using HMAC <xref target="RFC2403"/>. This provides
strong protection against configuration errors, replay attacks, and packet
corruption/modification.</t>
<t> This type of authentication is RECOMMENDED when there is limited control
over the administration of nodes on a LAN. While this type of authentication
does protect the operation of VRRP, there are other types of attacks that may
be employed on shared media links (e.g., generation of bogus ARP replies)
which are independent from VRRP and are not protected.<list>
<t> NOTE: It's a mistake to have AH be a RECOMMENDED in this context. Since
AH is the only mechanism that protects VRRP against attack from other nodes
on the same LAN, it should be a MUST for cases where there are untrusted
nodes on the same network. In any case, AH should be a MUST implement.</t>
<t> NOTE: There's an important piece of security analysis that's only hinted
at in this document, namely the cost/benefit tradeoff of VRRP
authentication.</t></list></t>
<t> [The rest of this section is NEW material]</t>
<t> The threat that VRRP authentication is intended to prevent is an attacker
arranging to be the VRRP master. This would be done by joining the group
(probably multiple times), gagging the master and then electing oneself
master. Such a node could then direct traffic in arbitrary undesirable
ways.</t>
<t> However, it is not necessary for an attacker to be the VRRP master to do
this. An attacker can do similar kinds of damage to the network by forging
ARP packets or (on switched networks) fooling the switch VRRP authentication
offers no real protection against these attacks.</t>
<t> Unfortunately, authentication makes VRRP networks very brittle in the face
of misconfiguration. Consider what happens if two nodes are configured with
different passwords. Each will reject messages from the other and therefore
both will attempt to be master. This creates substantial network
instability.</t>
<t> This set of cost/benefit tradeoffs suggests that VRRP authentication is a
bad idea, since the incremental security benefit is marginal but the
incremental risk is high. This judgment should be revisited if the current
set of non-VRRP threats are removed.</t>
</section>
</section>
</section>
</section>
<section anchor="ack" title="Acknowledgments">
<t> The previous version of this document was heavily based on a note written by Ran
Atkinson in 1997. That note was written after the IAB Security Workshop held in
early 1997, based on input from everyone at that workshop. Some of the specific
text above was taken from Ran's original document, and some of that text was taken
from an email message written by Fred Baker. The other primary source for that
document was specific comments received from Steve Bellovin. Early review of that
document was done by Lisa Dusseault and Mark Schertler. Other useful comments were
received from Bill Fenner, Ned Freed, Lawrence Greenfield, Steve Kent, Allison
Mankin and Kurt Zeilenga.</t>
<t> The previous version of this document was edited by Eric Rescorla and Brian
Korver with inputs from the other then current members of the IAB.</t>
</section>
<section anchor="iana_considerations" title="IANA Considerations">
<t> This document makes no requests of IANA.</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t> This entire document is about security considerations.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&rfc2119;
&rfc4302;
&rfc4033;
&rfc2946;
&rfc4303;
&rfc2743;
&rfc7230;
&rfc2403;
&rfc4120;
&rfc2289;
&rfc5280;
&rfc2505;
&rfc5231;
&rfc4422;
&rfc4954;
&rfc3207;
&rfc5751;
&rfc0854;
&rfc5246;
&rfc2817;
&rfc5798;
&rfc4253;
</references>
<references title="Informative References">
&rfc1414;
&rfc1704;
&rfc3977;
&rfc0791;
&rfc5322;
&rfc1939;
&rfc5406;
&rfc5925;
&rfc2818;
&rfc2522;
&rfc2693;
&rfc2660;
&rfc7322;
&rfc1738;
<reference anchor="TCPSYN" target="http://www.cert.org/advisories/CA-1996-21.html">
<front>
<title>TCP SYN Flooding and IP Spoofing Attacks</title>
<author/>
<date day="19" month="September" year="1996" />
</front>
<seriesInfo name='CERT Advisory' value='CA-1996-21' />
<format type='HTML' target='http://www.cert.org/advisories/CA-1996-21.html' />
</reference>
<reference anchor="DDOS" target="http://www.cert.org/advisories/CA-1999-17.html">
<front>
<title>Denial-Of-Service Tools</title>
<author />
<date day="28" month="December" year="1999" />
</front>
<seriesInfo name='CERT Advisory' value='CA-1999-17' />
<format type='HTML' target='http://www.cert.org/advisories/CA-1999-17.html' />
</reference>
<reference anchor="EKE">
<front>
<title>Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks</title>
<author initials="S." surname="Bellovin" fullname="Steve Bellovin">
<organization />
</author>
<author initials="M." surname="Merritt" fullname="M. Merritt">
<organization />
</author>
<date month="May" year="1992" />
</front>
<seriesInfo name='Proc. IEEE Symp.' value='on Research in Security and Privacy' />
</reference>
<reference anchor="IPSPPROB">
<front>
<title>Problem Areas for the IP Security Protocols</title>
<author initials="S. M." surname="Bellovin" fullname="Steve M. Bellovin">
<organization />
</author>
<date month="July" year="1996" />
</front>
<seriesInfo name='Proceedings' value='of the Sixth Usenix UNIX Security Symposium' />
</reference>
<reference anchor="KLEIN">
<front>
<title>Foiling the Cracker: A Survey of and Improvements to Password Security</title>
<author initials="D. V." surname="Klein" fullname="Daniel V. Klein">
<organization />
</author>
<date month="August" year="1990" />
</front>
<seriesInfo name='Proceedings' value='of the Second Usenix UNIX Security Workshop' />
</reference>
<reference anchor="SEQNUM">
<front>
<title>A Weakness in the 4.2 BSD UNIX TCP/IP Software</title>
<author initials="R. T." surname="Morris" fullname="Robert T. Morris">
<organization />
</author>
<date year="1985" />
</front>
<seriesInfo name='AT&T Bell Laboratories, CSTR' value='117' />
</reference>
<reference anchor="SOAP">
<front>
<title>Simple Object Access Protocol (SOAP) 1.1</title>
<author initials="D" surname="Box" fullname="Don Box">
<organization />
</author>
<author initials="D" surname="Ehnebuske" fullname="David Ehnebuske">
<organization />
</author>
<author initials="G" surname="Kakivaya" fullname="Gopal Kakivaya">
<organization />
</author>
<author initials="A" surname="Layman" fullname="Andrew Layman">
<organization />
</author>
<author initials="N" surname="Mendelsohn" fullname="Noah Mendelsohn">
<organization />
</author>
<author initials="H" surname="Nielsen" fullname="Henrik Frystyk Nielsen">
<organization />
</author>
<author initials="S" surname="Thatte" fullname="Satish Thatte">
<organization />
</author>
<author initials="D" surname="Winer" fullname="Dave Winer">
<organization />
</author>
<date month="May" day="8" year="2000" />
</front>
<seriesInfo name="W3C NOTE" value="NOTE-SOAP-20000508" />
<format type="HTML" target="http://www.w3.org/TR/2000/NOTE-SOAP-20000508" />
</reference>
<reference anchor="SPEKE">
<front>
<title>The SPEKE Password-Based Key Agreement Methods</title>
<author initials="D" surname="Jablon" fullname="David Jablon">
<organization/>
</author>
<date month="November" day="11" year="2002"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-jablon-speke-02"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-jablon-speke-02.txt"/>
</reference>
<reference anchor="SRP">
<front>
<title>The Secure Remote Password Protocol</title>
<author initials="T" surname="Wu" fullname="Tom Wu">
<organization>Stanford University</organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="ISOC NDSS Symposium" value=""/>
<format type="HTML" target="http://srp.stanford.edu/ndss.html"/>
</reference>
<reference anchor="WEP">
<front>
<title>Intercepting Mobile Communications: The Insecurity of 802.11</title>
<author initials="N" surname="Borisov" fullname="Nikita Borisov">
<organization>UC Berkeley</organization>
</author>
<author initials="I" surname="Goldberg" fullname="Ian Goldberg">
<organization>Zero-Knowledge Systems</organization>
</author>
<author initials="D" surname="Wagner" fullname="David Wagner">
<organization>UC Berkeley</organization>
</author>
<date month="July" year="2001"/>
</front>
<seriesInfo name="proceedings of the Seventh Annual International Conference on Mobile Computing And Networking" value=""/>
<format type="PDF" target="http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf"/>
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:02:09 |