WDIFF

draft-iab-sec-cons-03.txt-108693.txt --> rfc3552.txt

Network Working Group E. Rescorla
Request for Comments: 3552 RTFM, Inc.
BCP: 72 B. Korver
Category: Best Current Practice Xythos Software
Internet Architecture Board
INTERNET-DRAFT
IAB
<draft-iab-sec-cons-03.txt> January 2003 (Expires
July 2003) 2003

Guidelines for Writing RFC Text on Security Considerations

Status of this Memo

This document is specifies an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of Internet Best Current Practices for the
Internet Engineering Task Force (IETF), its areas, Community, and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Distribution of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It this memo is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). unlimited.

Abstract

All RFCs are required to have a Security Considerations section. His-
torically,
Historically, such sections have been relatively weak. This document
provides guidelines to RFC authors on how to write a good Security
Considerations section.

Table of Contents

1. Introduction

All RFCs are required by [RFC 2223] to contain a Security Considera-
tions 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.

This document is structured in three parts. The first is a combina-
tion security tutorial and definition of common terms; the second is
a series of guidelines for writing Security Considerations; the third

Rescorla, Korver [Page 1]

is a series of examples. . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS] Requirements. . . . . . . . . . . . . . . . . . . . . 3
2. The Goals of Security

Most people speak of security as if it were a single monolithic prop-
erty of a protocol or system, but upon reflection that's very clearly
not true. Rather, security is a series of related but somewhat inde-
pendent properties. Not all of these properties are required for
every application.

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 SYS-
TEM 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. Security. . . . . . . . . . . . . . . . . . . 3
2.1. Communication Security

Different authors partition the goals of communication security dif-
ferently. The partitioning we've found most useful is to divide them
into three major categories: CONFIDENTIALITY, DATA INTEGRITY and PEER
ENTITY AUTHENTICATION. Security. . . . . . . . . . . . . . . . 3
2.1.1. Confidentiality

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, that poses a risk to your confidentiality.

Obviously, if you have secrets, you're concerned that no-one else
knows them and so at minimum you want 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. Confidentiality. . . . . . . . . . . . . . . . 4
2.1.2. Data Integrity

The second primary goal is DATA INTEGRITY. The basic idea here is
that we want to be sure that the data we receive is the one that the
sender sent. In paper-based systems, some data integrity comes auto-
matically. When you receive a letter written in pen you can be fairly

Rescorla, Korver [Page 2]Internet-Draft Security Considerations Guidelines

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.

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 recopy-
ing the message, changing it as he does it. It's just a lot easier to
do electronically since all bits look alike. . . . . . . . . . . . . . . . . 4
2.1.3. Peer Entity authentication

The third property we're concerned with is PEER ENTITY AUTHENTICA-
TION. 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.

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.

In messaging situations, you often wish to use peer entity authenti-
cation to establish the identity of the sender of a certain message.
In such contexts, this property is called DATA ORIGIN AUTHENTICATION. . . . . . . . . . . 4
2.2. Non-Repudiation

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

Rescorla, Korver [Page 3]

this fact to a third party. The ability to make this demonstration is
called NON-REPUDIATION.

There are many situations in which non-repudiation is desirable. Con-
sider 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.

Unfortunately, non-repudiation can be very difficult to achieve in
practice and naive approaches are generally inadequate. Section 4.3
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. . . . . . . . . . . . . . . . . . . . 5
2.3. Systems Security

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. Fur-
thermore, they should be available for those purposes. Attackers
should not be able to deprive legitimate users of resources. Security. . . . . . . . . . . . . . . . . . . 5
2.3.1. Unauthorized Usage

Most systems are not intended to be completely accessible to the pub-
lic. 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. . . . . . . . . . . . . . . 6
2.3.2. Inappropriate Usage

Being an authorized user does not mean that you have free run of the
system. As we said above, some activities are restricted to autho-
rized users, some to specific users, and some activities are gener-
ally 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.

Rescorla, Korver [Page 4]Internet-Draft Security Considerations Guidelines Usage. . . . . . . . . . . . . . 6
2.3.3. Denial of Service

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. Service. . . . . . . . . . . . . . . 6
3. The Internet Threat Model

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.

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 extraordi-
narily difficult. It is, however, possible to design protocols which
minimize the extent of the damage done under these circumstances.

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.

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 RFC-822 message or a single SMTP command. At the
HTTP level, it might mean a request or response.

Rescorla, Korver [Page 5]

3.1. Limited Threat Models

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 [INTAUTH]

By contrast, Morris's sequence number guessing attack [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.

Thus, a useful way of organizing attacks is to divide them based on
the capabilities required to mount the attack. The rest of this sec-
tion describes these categories and provides some examples of each
category.

3.2. Passive Attacks

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 configu-
rations, 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.

Similarly, an attacker who has control of a host in the communica-
tions 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.

Wireless communications channels deserve special consideration, espe-
cially 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.
[WEP]

Rescorla, Korver [Page 6]Internet-Draft Security Considerations Guidelines

In general, the goal of a passive attack is to obtain information
which the sender and receiver would rather remain private. Examples
of such information include credentials useful in the electronic
world such as passwords or credentials useful in the outside world,
such as confidential business information.

3.2.1. Confidentiality Violations

The classic example of passive attack is sniffing some inherently
private data off of the wire. For instance, despite the wide avail-
ability 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 fraud-
ulent transactions. Moreover, confidential business information is
routinely transmitted over the network in the clear in email.

3.2.2. Password Sniffing

Another example of a passive attack is PASSWORD SNIFFING. Password
sniffing is directed towards obtaining unauthorized use of resources.
Many protocols, including [TELNET], [POP], and [NNTP] 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 traf-
fic can therefore capture the password and REPLAY it. That is to say
that he can initiate a connection to the server and pose as the
client and login using the captured password.

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.

3.2.3. Offline Cryptographic Attacks

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.

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 [KLEIN]. When NIS is

Rescorla, Korver [Page 7]

used, the crypted password is transmitted over the local network and
an attacker can thus sniff the password and attack it.

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.

3.3. Active Attacks

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.

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 protec-
tion against an attacker who is inside the firewall. In general,
designers should assume that attackers can forge packets.

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.

Each protocol is susceptible to specific active attacks, but experi-
ence 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 pro-
tocols.

3.3.1. Replay Attacks

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

Rescorla, Korver [Page 8]Internet-Draft Security Considerations Guidelines

them.

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.

3.3.2. Message Insertion

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.

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.

3.3.3. Message Deletion

In a MESSAGE DELETION attack, the attacker removes a message from the
wire. Morris's sequence number guessing attack [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.

3.3.4. Message Modification

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.

Rescorla, Korver [Page 9]

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.

Another interesting example of a cut-and-paste attack is provided by
[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.

3.3.5. Man-In-The-Middle

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:

What Alice and Bob think:
Alice <----------------------------------------------> Bob

What's happening:
Alice <----------------> Attacker <----------------> Bob

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.

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

Rescorla, Korver [Page 10]Internet-Draft Security Considerations Guidelines

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.

Note that it is only necessary to authenticate one side of the trans-
action in order to prevent man-in-the-middle attacks. In such a situ-
ation 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 accept-
able 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).

3.4. Topological Issues

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.

3.5. On-path versus off-path

In order for a datagram to be transmitted from one host to another,
it generally must traverse some set of intermediate links and gate-
ways. 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.

Off-path hosts can, of course, transmit arbitrary datagrams that
appear to come from any hosts but cannot necessarily receive data-
grams 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-pth. This is by no means impossible
but is not necessarily trivial.

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 net-
work. However, designers are expected to give more weight to attacks
which can be mounted by off-path attackers as well as on-path ones.

3.6. Link-local

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. [IP] Since the TTL must be

Rescorla, Korver [Page 11]

decremented by each forwarder, a protocolcan demands 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 tunnelling systems, since such systems may pass packets without
decrementing TTL.

4. Common Issues

Although each system's security requirements are unique, certain com-
mon 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 avail-
able. This section describes a number of issues seen in many proto-
cols and the common pieces of security technology that may be useful
in addressing them.

4.1. User Authentication

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.

4.1.1. Username/Password

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.

4.1.2. Challenge Response and One Time Passwords

Systems which desire greater security than USERNAME/PASSWORD often
employ either a ONE TIME PASSWORD [OTP] 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

Rescorla, Korver [Page 12]Internet-Draft Security Considerations Guidelines

to the host, which verifies it. Often this computation is performed
in a handheld device, such as a DES Gold card.

Both types of scheme provide protection against replay attack, but
often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of pas-
sive 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 eas-
ier 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.

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.

4.1.3. Shared Keys

CHALLENGE-RESPONSE type systems can be made secure against dictionary
attack by using randomly generated shared keys instead of user-gener-
ated 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.

Like password-based systems, shared key systems suffer from manage-
ment problems. Each pair of communicating parties must have their own
agreed-upon key, which leads to there being a lot of keys.

4.1.4. Key Distribution Centers

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 DISTRIBU-
TION CENTER (KDC)) shares a symmetric key or password with each party
in the system. another party, 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 associa-
tion. By far the most popular KDC system is Kerberos. [KERBEROS]

4.1.5. Certificates

A simple approach is to have all users have CERTIFICATES [PKIX] which
they then use to authenticate in some protocol-specific way, as in

Rescorla, Korver [Page 13]

[TLS] or [S/MIME]. 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.

4.1.6. Some Uncommon Systems

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 con-
nection after authentication has been performed. A number of proto-
cols ( [EKE], [SPEKE], [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.

4.1.7. Host Authentication

Host authentication presents a special problem. Quite commonly, the
addresses of services are presented using a DNS hostname, for
instance as a URL [URL]. 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 bind-
ing between the certificate and the expected hostname.

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 res-
olution [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.

4.2. Generic Security Frameworks

Providing security functionality in a protocol can be difficult. In
addition to the problem of choosing authentication and key establish-
ment mechanisms, one needs to integrate it into a protocol. One

Rescorla, Korver [Page 14]Internet-Draft Security Considerations Guidelines

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 mech-
anisms in a pluggable fashion. Application protocol designers then
arrange to carry the security protocol PDUs in their application pro-
tocol. Examples of such frameworks include GSS-API [GSS] and SASL
[SASL].

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 algo-
rithm. 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.

Another problem is that it's not always obvious how the various secu-
rity 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.

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 secu-
rity 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 situa-
tions 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.

Rescorla, Korver [Page 15]

4.3. Non-repudiation

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 sig-
nature as proof that the signing party at one point agreed to the
disputed message. Unfortunately, this approach is insufficient.

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 dis-
puted 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 Model. . . . . . . . . . . . . . . . . 6
3.1. Limited Threat Models . . . . . . . . . . . . . . . . 7
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . 7
3.2.1. Confidentiality Violations . . . . . . . . . . 8
3.2.2. Password Sniffing. . . . . . . . . . . . . . . 8
3.2.3. Offline Cryptographic Attacks. . . . . . . . . 9

Rescorla & Korver Best Current Practice [Page 1]

RFC 3552 Security Considerations Guidelines July 2003

3.3. Active Attacks. . . . . . . . . . . . . . . . . . . . 9
3.3.1. Replay Attacks . . . . . . . . . . . . . . . . 10
3.3.2. Message Insertion. . . . . . . . . . . . . . . 10
3.3.3. Message Deletion . . . . . . . . . . . . . . . 11
3.3.4. Message Modification . . . . . . . . . . . . . 11
3.3.5. Man-In-The-Middle. . . . . . . . . . . . . . . 12
3.4. Topological Issues. . . . . . . . . . . . . . . . . . 12
3.5. On-path versus off-path . . . . . . . . . . . . . . . 13
3.6. Link-local. . . . . . . . . . . . . . . . . . . . . . 13
4. Common Issues. . . . . . . . . . . . . . . . . . . . . . . 13
4.1. User Authentication . . . . . . . . . . . . . . . . . 14
4.1.1. Username/Password. . . . . . . . . . . . . . . 14
4.1.2. Challenge Response and timestamp servers to establish the time that the mes-
sage was signed.

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.

All of these complications make non-repudiation a difficult service
to deploy in practice. One Time Passwords. . . 14
4.1.3. Shared Keys. . . . . . . . . . . . . . . . . . 15
4.1.4. Key Distribution Centers . . . . . . . . . . . 15
4.1.5. Certificates . . . . . . . . . . . . . . . . . 15
4.1.6. Some Uncommon Systems. . . . . . . . . . . . . 15
4.1.7. Host Authentication. . . . . . . . . . . . . . 16
4.2. Generic Security Frameworks . . . . . . . . . . . . . 16
4.3. Non-repudiation . . . . . . . . . . . . . . . . . . . 17
4.4. Authorization vs. Authentication

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 mistak-
enly thought to imply authorization. Authentication simply identifies
a party, authorization defines whether they can perform a certain
action.

Authorization necessarily relies on authentication, but authentica-
tion alone does not imply authorization. Rather, before granting per-
mission to perform an action, the authorization mechanism must be
consulted to determine whether that action is permitted.

Rescorla, Korver [Page 16]Internet-Draft Security Considerations Guidelines Authentication. . . . . . . . . . . 18
4.4.1. Access Control Lists

One common form . . . . . . . . . . . . . 18
4.4.2. Certificate Based Systems. . . . . . . . . . . 18
4.5. Providing Traffic Security. . . . . . . . . . . . . . 19
4.5.1. IPsec. . . . . . . . . . . . . . . . . . . . . 19
4.5.2. SSL/TLS. . . . . . . . . . . . . . . . . . . . 20
4.5.3. Remote Login . . . . . . . . . . . . . . . . . 22
4.6. Denial of authorization mechanism is an access control list
(ACL) that lists users that are permitted access to a resource. Since
assigning individual authorization permissions to each resource is
tedious, often resources are hierarchically arranged such that the
parent resource's ACL is inherited by child resources. This allows
administrators to set top level policies and override them when nec-
essary.

4.4.2. Certificate Based Systems

While the distinction between authentication and authorization is
intuitive when using simple authentication mechanisms such as user-
name 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.

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, Service Attacks and that root must be
trusted in the given context. For instance, users who possess cer-
tificates 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 Countermeasures . . . . 22
4.6.1. Blind Denial of these CAs are "trusted" by the
Acme web server.

Mechanisms for enforcing these more complicated properties have not
yet been completely explored. One approach is simply to attach poli-
cies to ACLs describing what sorts Service. . . . . . . . . . . . 23
4.6.2. Distributed Denial of Service. . . . . . . . . 23
4.6.3. Avoiding Denial of certificates are trusted.
Another approach is to carry that information with the certificate,
either as a certificate extension/attribute [PKIX, SPKI] or as a sep-
arate "Attribute Certificate".

4.5. Providing Traffic Service . . . . . . . . . . 24
4.6.4. Example: TCP SYN Floods. . . . . . . . . . . . 24
4.6.5. Example: Photuris. . . . . . . . . . . . . . . 25
4.7. Object vs. Channel Security

Securely designed protocols should provide some mechanism for secur-
ing (meaning integrity protecting, authenticating, . . . . . . . . . . . . . 25
4.8. Firewalls and possibly
encrypting) all sensitive traffic. One approach is to secure the pro-
tocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this
provides Network Topology. . . . . . . . . . . . 26
5. Writing Security Considerations Sections . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. SMTP. . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. Security Considerations. . . . . . . . . . . . 29
6.1.2. Communications security which is most fitted to the protocol, it also
requires considerable effort to get right.

Many protocols can be adequately secured using one issues . . . . . . . . 34
6.1.3. Denial of the available
channel security systems. We'll discuss the two most common, IPsec
[AH, ESP] and [TLS].

Rescorla, Service. . . . . . . . . . . . . . . 36
6.2. VRRP. . . . . . . . . . . . . . . . . . . . . . . . . .36
6.2.1. Security Considerations. . . . . . . . . . . . 36
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 38
8. Normative References . . . . . . . . . . . . . . . . . . . 39
9. Informative References . . . . . . . . . . . . . . . . . . 41
10.Security Considerations. . . . . . . . . . . . . . . . . . 42
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 43

Rescorla & Korver Best Current Practice [Page 17]

4.5.1. IPsec

The IPsec protocols (specifically, AH and ESP) can provide transmis-
sion 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 identifica-
tion 2]

RFC 3552 Security Considerations Guidelines July 2003

Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 43
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 44

1. Introduction

All RFCs are employed as inputs required by RFC 2223 to access control facilities that are an
intrinsic part of IPsec. However, contain 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.

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.

The primary obstacle to using IPsec to secure other protocols is
deployment. Security
Considerations section. The major use purpose of IPsec at present is for VPN applica-
tions, especially for remote network access. Without extremely tight
coordination between security administrators and application develop-
ers, VPN usage this is not well suited both to providing security services for
individual applications since it is difficult for such applications encourage
document authors to determine what consider security services have in fact been provided.

IPsec deployment in host-to-host environments has been slow. Unlike
application security systems such as TLS, adding IPsec their designs and to a non-IPsec
system generally involves changing the operating system, either by
modifying with inform
the kernel or installing new drivers. reader of relevant security issues. This memo is a sub-
stantially greater undertaking than simply installing a new applica-
tion. However, recent versions intended to
provide guidance to RFC authors in service of both ends.

This document is structured in three parts. The first is a number
combination security tutorial and definition of commodity operating
systems include IPsec stacks, so deployment is becoming easier.

In environments where IPsec common terms; the
second is sure to be available, it represents a
viable option series of guidelines for protecting application communications traffic. If writing Security Considerations;
the traffic to be protected third is UDP, IPsec a series of examples.

1.1. Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and application-specific
object security "OPTIONAL" in this
document are the only options. However, designers MUST NOT
assume that IPsec will to be available. A interpreted as described in BCP 14, RFC 2119
[KEYWORDS].

2. The Goals of Security

Most people speak of security policy for as if it were a single monolithic
property of a generic
application layer protocol SHOULD not simply state or system, however, upon reflection, one
realizes that IPsec must be
used, unless there it is some reason to believe that IPsec will be
available in the intended deployment environment. In environments
where IPsec may clearly not be available and the traffic true. Rather, security is solely TCP, TLS a series
of related but somewhat independent properties. Not all of these
properties are required for every application.

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.

2.1. Communication Security

Different authors partition the method goals of choice, since the application developer can easily
ensure its presence by including a TLS implementation in his package.

Rescorla, 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.

Rescorla & Korver Best Current Practice [Page 18]Internet-Draft 3]

RFC 3552 Security Considerations Guidelines

In the special-case July 2003

2.1.1. Confidentiality

When most people think of IPv6, both AH and ESP security, they think of CONFIDENTIALITY.
Confidentiality means that your data is kept secret from unintended
listeners. Usually, these listeners are mandatory to imple-
ment. Hence, simply eavesdroppers. When
an adversary taps your phone, it is reasonable poses a risk to assume that AH/ESP your
confidentiality.

Obviously, if you have secrets, then you are already
available for IPv6-only protocols or IPv6-only deployments. However,
automatic key management (IKE) is not required probably concerned about
others discovering them. Thus, at the very least, you want to implement so proto-
col designers SHOULD not assume it will be present. [USEIPSEC] pro-
vides quite a bit of guidance
maintain confidentiality. When you see spies in the movies go into
the bathroom and turn on when IPsec is a good choice.

4.5.2. SSL/TLS

The currently most common approach is all the water to use SSL or its successor
TLS. They provide channel security for a TCP connection at foil bugging, the appli-
cation level. That is, they run over TCP. SSL implementations typi-
cally provide a Berkeley Sockets-like interface property
they're looking for easy programming. is confidentiality.

2.1.2. Data Integrity

The second primary issue when designing a protocol solution around TLS goal is to
differentiate between connections protected using TLS and those which
are not. DATA INTEGRITY. The two primary approaches used are basic idea here is
that we want to have a separate well-known
port for TLS connections (e.g. make sure that the HTTP over TLS port data we receive is 443)
[HTTPTLS] or to have a mechanism for negotiating upward from the base
protocol to TLS as in [UPGRADE] or [STARTTLS]. same data
that the sender has sent. In paper-based systems, some data
integrity comes automatically. When an upward negoti-
ation strategy is used, care must you receive a letter written in
pen you can be taken to ensure fairly certain that no words have been removed by an
attacker
can not force a clear connection when both parties wish to use TLS.

Note that TLS depends upon a reliable protocl 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 because pen marks are difficult to
IP layer attacks that IPsec is not. Typically, these attacks take
some form of denial of service or connection assassination. For
instance, remove from paper.
However, an attacker might forge a TCP RST could have easily added some marks to shut down SSL connec-
tions. TLS has mechanisms the paper
and completely changed the meaning of the message. Similarly, it's
easy to detect truncation attacks but these
merely allow shorten the page to truncate the message.

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 victim to know he recipient is no wiser. This is being attacked and do not pro-
vide connection survivability in the face moral equivalent of such attacks. By con-
trast, if IPsec were being used, such a forged RST could be rejected
without affecting the TCP conection. If forged RSTs or other such
attacks on the TCP connection are
attacker taking a concern, then AH/ESP or the TCP
MD5 option [TCPMD5] are the preferred choices.

4.5.2.1. Virtual Hosts

If letter you wrote, buying some new paper and
recopying the "separate ports" approach message, changing it as he does it. It's just a lot
easier to TLS do electronically since all bits look alike.

2.1.3. Peer Entity authentication

The third property we're concerned with is used, then TLS will be
negotiated before any application-layer traffic PEER ENTITY
AUTHENTICATION. What we mean by this is sent. This can
cause a problem with protocols that use virtual hosts, such as
[HTTP], since the server does not we know which certificate to offer that one of the
client during
endpoints in the TLS handshake. The TLS hostname extension [TLSEXT]
can be used communication is the one we intended. Without peer
entity authentication, it's very difficult to solve this problem, although 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 is was in fact sent by Alice and not the
attacker. Similarly, if we want to new send a confidential message to
Bob, it's not of much value to us if we're actually sending a
confidential message to have seen
wide deployment.

Rescorla, the attacker.

Rescorla & Korver Best Current Practice [Page 19]

4.5.2.2. Remote Authentication and TLS

One difficulty with using TLS is 4]

RFC 3552 Security Considerations Guidelines July 2003

Note that peer entity authentication can be provided asymmetrically.
When you call someone on the server is authenticated via
a certificate. This phone, you can be inconvenient in environments where previ-
ously fairly certain that
you have 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 right person -- or at least that you got a self-signed RSA certificate) and person who's
actually at the phone number you called. On the other hand, if they
don't have caller ID, then authenticate via some challenge-response mechanism such as SASL
with CRAM-MD5.

Unfortunately, this composition the receiver of SASL and TLS a phone call has no idea
who's calling them. Calling someone on the phone is less strong than
one would expect. It's easy for an active attacker example of
recipient authentication, since you know who the recipient of the
call is, but they don't know anything about the sender.

In messaging situations, you often wish to hijack this
connection. The client man-in-the-middles use peer entity
authentication to establish the SSL connection (remem-
ber we're not authenticating identity of the server, which is what ordinarily
prevents sender of a certain
message. In such contexts, this attack) and then simply proxies property is called DATA ORIGIN
AUTHENTICATION.

2.2. Non-Repudiation

A system that provides endpoint authentication allows one party to be
certain of the SASL handshake.
From then on, it's as if identity of someone with whom he is communicating.
When the connection were in system provides data integrity a receiver can be sure of
both the clear, at least
as far as sender's identity and that attacker he is concerned. In order to prevent this
attack, receiving the client needs data that
that sender meant to verify the server's certificate. send. However, if the server he cannot necessarily
demonstrate this fact to a third party. The ability to make this
demonstration is called NON-REPUDIATION.

There are many situations in which non-repudiation is authenticated, challenge-response becomes
less desirable. If you already
Consider the situation in which two parties have signed a hardened channel then simple
passwords are fine. In fact, they're arguably superior contract
which one party wishes to challenge-
response since they do not require unilaterally abrogate. He might simply
claim that he had never signed it in the password first place. Non-
repudiation prevents him from doing so, thus protecting the
counterparty.

Unfortunately, non-repudiation can be stored very difficult to achieve in
practice and naive approaches are generally inadequate. Section 4.3
describes some of the
clear on difficulties, which generally stem from the server. Thus, compromise
fact that the interests of the key file with challenge-
response two parties are not aligned -- one
party wishes to prove something that the other party wishes to deny.

2.3. Systems Security

In general, systems security is concerned with protecting one's
machines and data. The intent is more serious than if simple passwords were used.

Note that if the client has a certificate than SSL-based client
authentication can machines should be used. To make this easier, SASL provides the
EXTERNAL mechanism, whereby the SASL client can tell used only
by authorized users and for the server
"examine purposes that the outer channel owners intend.
Furthermore, they should be available for my identity". Obviously, this is those purposes. Attackers
should not
subject be able to deprive legitimate users of resources.

Rescorla & Korver Best Current Practice [Page 5]

RFC 3552 Security Considerations Guidelines July 2003

2.3.1. Unauthorized Usage

Most systems are not intended to the layering attacks described above.

4.5.3. Remote Login

In some special cases it may be worth providing channel-level secu-
rity directly in completely accessible to the application rather than using IPSEC or SSL/TLS.
One such case is remote terminal security. Characters
public. Rather, they are typically
delivered from client intended to server one character at a time. Since
SSL/TLS and AH/ESP authenticate and encrypt every packet, this can
mean be used only by certain
authorized individuals. Although many Internet services are
available to all Internet users, even those servers generally offer a data expansion
larger subset of 20-fold. The telnet encryption option
[ENCOPT] prevents this expansion by foregoing message integrity.

When using remote terminal service, it's services to specific users. For instance, Web
Servers often desirable will serve data to securely
perform other sorts of communications services. In addition any user, but restrict the ability
to pro-
viding remote login, SSH [SSH] also provides secure port forwarding
for arbitrary TCP ports, thus allowing users run arbitrary TCP-based
applications over modify pages to specific users. Such modifications by the SSH channel. Note that SSH Port Forwarding can general
public would be security issue if it is used improperly UNAUTHORIZED USAGE.

2.3.2. Inappropriate Usage

Being an authorized user does not mean that you have free run of the
system. As we said above, some activities are restricted to circumvent firewall and

Rescorla, Korver [Page 20]Internet-Draft Security Considerations Guidelines

improperly expose insecure internal applications
authorized users, some to the outside
world.

4.6. Denial of Service Attacks specific users, and Countermeasures

Denial of service attacks some activities are
generally forbidden to all too frequently viewed as an fact of
life. One problem is that an attacker can often choose 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 one sending files above a certain size, or files which
contain viruses. These are examples of
many denial INAPPROPRIATE USAGE.

2.3.3. Denial of service attacks Service

Recall that our third goal was that the system should be available to inflict upon a victim, and because
most
legitimate users. A broad variety 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 possible which
threaten such usage. Such attacks
that are possible but that cannot be prevented.

However, not all denial collectively referred to as
DENIAL OF SERVICE attacks. Denial of service attacks are equal often very
easy to mount and more impor-
tantly, it is possible difficult to design protocols stop. Many such that denial of ser-
vice attacks are made more designed
to consume machine resources, making it difficult if not impractical. Recent SYN
flood attacks [TCPSYN] demonstrate both of these properties: SYN
flood or impossible to
serve legitimate users. Other attacks are so easy, anonymous, and effective that they are
more attractive cause the target machine to
crash, completely denying service to attackers than other attacks; and because users.

3. The Internet Threat Model

A THREAT MODEL describes the
design of TCP enables this attack.

Because complete DoS protection capabilities that an attacker is so difficult, security against DoS
must be dealt with pragmatically. In particular, some attacks which
would be desirable assumed
to defend against cannot be defended against eco-
nomically. The goal should be able to manage risk by defending deploy against
attacks with sufficiently high ratios of severity a resource. It should contain such
information as the resources available to cost of defense.
Both severity an attacker in terms of attack
information, computing capability, and cost control of defense change as technology
changes and therefore so does the set of attacks which should be
defended against.

Authors of internet standards MUST describe which denial system. The
purpose of service
attacks their protocol a threat model is susceptable to. This description MUST
include twofold. First, we wish to identify the reasons it was either unreasonable or
threats we are concerned with. Second, we wish to rule some threats
explicitly out of scope to
attempt scope. Nearly every security system is vulnerable
to avoid these denial of service attacks.

4.6.1. Blind Denial of Service

BLIND denial of service attacks are particularly pernicious. With a
blind sufficiently dedicated and resourceful attacker.

Rescorla & Korver Best Current Practice [Page 6]

RFC 3552 Security Considerations Guidelines July 2003

extraordinarily difficult. It is, however, possible to design
protocols which minimize the extent of the damage done under these
circumstances.

By contrast, we assume that the attacker has a significant advantage. If nearly complete control
of the communications channel over which the end-systems communicate.
This means that the attacker must be 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 receive traffic generate packets that
appear to be from a trusted machine. Thus, even if the victim then he must
either subvert end-system
with which you wish to communicate is itself secure, the routing fabric or must use his own IP address.
Either Internet
environment provides an opportunity for victim no assurance that packets which claim to track be from
that system in fact are.

It's important to realize that the attacker
and/or filter out his traffic. With meaning of a blind attack PDU is different at
different levels. At the attacker can
use forged IP addresses, making it extremely difficult for level, a PDU means an IP packet. At the victim
to filter out his packets. The
TCP SYN flood attack is an example of level, it means a blind attack. Designers should make every attempt possible to pre-
vent blind denial of service attacks.

Rescorla, Korver [Page 21]

4.6.2. Distributed Denial TCP segment. At the application layer, it
means some kind of Service

Even more dangerous are DISTRIBUTED denial application PDU. For instance, at the level of service attacks (DDoS)
[DDOS] In
email, it might either mean an RFC-822 message or a single SMTP
command. At the HTTP level, it might mean a request or response.

3.1. Limited Threat Models

As we've said, a DDoS the resourceful and dedicated attacker arranges for a number of machines to
attack can control the target machine simultaneously. Usually this is accom-
plished by infecting
entire communications channel. However, a large number of machines attacks
can be mounted by an attacker with a program that
allows remote initiation fewer resources. A number of attacks. The machines actually performing
the attack are called ZOMBIEs and are likely owned
currently known attacks can be mounted by unsuspecting
third parties in an entirely different location from attacker with limited
control of the true
attacker. DDoS network. For instance, password sniffing attacks can
be very hard to counter because the zom-
bies often appear mounted by an attacker who can only read arbitrary packets. This
is generally referred to be making legitimate protocol requests and sim-
ply crowd out the real users. DDoS attacks as a PASSIVE ATTACK [INTAUTH].

By contrast, Morris' sequence number guessing attack [SEQNUM] can be difficult to
thwart,
mounted by an attacker who can write but protocol designers are expected to be cognizant of these
forms of not read arbitrary packets.
Any attack while designing protocols.

4.6.3. Avoiding Denial of Service

There are two common approaches to making denial of service attacks
more difficult:

4.6.3.1. Make your attacker do more work than you do

If an which requires the attacker consumes more of his resources than yours when launch-
ing an attack, attackers with fewer resources than you will be unable to launch effective attacks. One common technique is write to require the
attacker perform a time-intensive operation, such network is
known as a cryptographic
operation. Note that an attacker can still ACTIVE ATTACK.

Thus, a useful way of organizing attacks is to divide them based on
the capabilities required to mount a denial the attack. The rest of service
attack if he can muster substantially sufficient CPU power. For
instance, this technique would not stop
section describes these categories and provides some examples of each
category.

3.2. Passive Attacks

In a passive attack, the distributed attacks
described in [TCPSYN].

4.6.3.2. Make your attacker prove they can receive data from you

A blind reads packets off the network but
does not write them. The simplest way to mount such an attack can is to
simply be subverted by forcing on the attack prove that they
can can receive data from same LAN as the victim. A On most common technique is to
require LAN
configurations, including Ethernet, 802.3, and FDDI, any machine on
the wire can read all traffic destined for any other machine on the

Rescorla & Korver Best Current Practice [Page 7]

RFC 3552 Security Considerations Guidelines July 2003

same LAN. Note that switching hubs make this sort of sniffing
substantially more difficult, since traffic destined for a machine
only goes to the attacker reply using information network segment which that was gained
earlier machine is on.

Similarly, an attacker who has control of a host in the message exchange. If this countermeasure
communications path between two victim machines is used, the
attacker must either use his own address (making him easy able to track)
or mount a
passive attack on their communications. It is also possible to forge
compromise the routing infrastructure to specifically arrange that
traffic passes through a compromised machine. This might involve an address which will be routed back along
active attack on the routing infrastructure to facilitate a passive
attack on a path that
traverses victim machine.

Wireless communications channels deserve special consideration,
especially with the host from which recent and growing popularity of wireless-based
LANs, such as those using 802.11. Since the attack data is being launched.

Hosts simply broadcast
on small subnets well known radio frequencies, an attacker simply needs to be able
to receive those transmissions. Such channels are thus useless especially
vulnerable to the attacker (at least in
the context passive attacks. Although many such channels include
cryptographic protection, it is often of a spoofing attack) because the attack can be traced
back such poor quality as to a subnet (which should be sufficient for locating
nearly useless [WEP].

In general, the
attacker) so that anti-attack measures can be put into place (for
instance, goal of a boundary router can be configured to drop all traffic
from that subnet). A common technique passive attack is to require that obtain information
which the attacker
reply using sender and receiver would prefer to remain private. This
private information that was gained earlier may include credentials useful in the message

Rescorla, Korver [Page 22]Internet-Draft Security Considerations Guidelines

exchange.

4.6.4. Example: TCP SYN Floods

TCP/IP is vulnerable to SYN flood attacks (which are described electronic
world and/or passwords or credentials useful in
section 3.3.2) because of the design outside world,
such as confidential business information.

3.2.1. Confidentiality Violations

The classic example of passive attack is sniffing some inherently
private data off 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 wire. For instance, despite the wide
availability of SSL, many credit card transactions still traverse the
attacker can perform this action without ever having received data
from
Internet in the victim, clear. An attacker could sniff such a message and
recover the attack credit card number, which can then be performed anonymously (and there-
fore using used to make
fraudulent transactions. Moreover, confidential business information
is routinely transmitted over the network in the clear in email.

3.2.2. Password Sniffing

Another example of a large number passive attack is PASSWORD SNIFFING. Password
sniffing is directed towards obtaining unauthorized use of forged source addresses).

4.6.5. Example: Photuris

[PHOTURIS] specifies an anti-clogging mechanism that prevents attacks
on Photuris that resemble the SYN flood attack. Photuris employs resources.
Many protocols, including [TELNET], [POP], and [NNTP] use a
time-variant secret shared
password to generate a "cookie" which authenticate the client to the server. Frequently, this
password is returned transmitted from the client to the
attacker. This cookie must be returned server in subsequent messages for the
exchange to progress. The interesting feature is that clear
over the communications channel. An attacker who can read this cookie
traffic can
be re-generated by the victim later in therefore capture the exchange, password and thus no
state need be retained by the victim until after REPLAY it. In other
words, the attacker has
proven that he can receive packets from the victim.

4.7. Object vs. Channel Security

It's useful initiate a connection to make the conceptual distinction between object secu-
rity server and channel security. Object security refers to security mea-
sures which apply to entire data objects. Channel security measures
provide a secure channel over which objects may be carried transpar-
ently but pose
as the channel has no special knowledge about object bound-
aries.

Consider client and login using the captured password.

Rescorla & Korver Best Current Practice [Page 8]

RFC 3552 Security Considerations Guidelines July 2003

Note that although the case login phase of an email message. When it's carried over an
IPSEC or TLS secured connection, the message attack is protected during
transmission. However, it active, the
actual password capture phase is unprotected in passive. Moreover, unless the receiver's mailbox,
and in intermediate spool files along
server checks the way. Moreover, since mail
servers generally run as a daemon, not a user, authentication of mes-
sages generally merely means authentication originating address of connections, the daemon login phase
does not require any special control of the
user. Finally, since mail transport is hop-by-hop, even if the user
authenticates network.

3.2.3. Offline Cryptographic Attacks

Many cryptographic protocols are subject to OFFLINE ATTACKS. In such
a protocol, the first hop relay the authentication can't be
safely verified by the receiver.

By contrast, when an email message is protected with S/MIME or
OpenPGP, attacker recovers data which has been processed using
the entire message is encrypted victim's secret key and integrity protected
until it is examined 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 decrypted by the recipient. It also provides
strong authentication then proceeds to
try entries from a list of the actual sender, common words (such as opposed a dictionary file)
until he finds a password that produces the right response.

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 [KLEIN]. When NIS is
used, the machine
the message came from. This crypted password is object security. Moreover, transmitted over the
receiver local network and
an attacker can prove the signed message's authenticity to a third

Rescorla, Korver [Page 23]

party.

Note that thus sniff the difference between object password and channel security is a
matter of perspective. Object security at one layer of the protocol
stack often looks like channel attack it.

Historically, it has also been possible to exploit small operating
system security at holes to recover the next layer up. So,
from password file using an active
attack. These holes can then be bootstrapped into an actual account
by using the perspective of aforementioned offline password recovery techniques.
Thus we combine a low-level active attack with an offline passive
attack.

3.3. Active Attacks

When an attack involves writing data to the IP layer, each packet looks like network, we refer to this
as an indi-
vidually secured object. But from ACTIVE ATTACK. When IP is used without IPsec, there is no
authentication for the perspective of a web client,
IPSEC just provides sender address. As a secure channel.

The distinction isn't always clear-cut. For example, S-HTTP provides
object level security consequence, it's
straightforward for an attacker to create a single HTTP transaction, but packet with a web page
typically consists source
address of multiple HTTP transactions (the base page and
numerous inline images.) Thus, from his choosing. We'll refer to this as a SPOOFING ATTACK.

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 perspective of INTERNAL network that arrive
on the total web
page, EXTERNAL interface. Note, however, that this looks rather more like channel security. Object security
for a web page would consist of security for provides no
protection against an attacker who is inside the transitive closure
of firewall. In
general, designers should assume that attackers can forge packets.

Rescorla & Korver Best Current Practice [Page 9]

RFC 3552 Security Considerations Guidelines July 2003

However, the page and all its embedded content 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 a single unit.

4.8. Firewalls and Network Topology

It's BLIND ATTACKS.

Note that not all active attacks require forging addresses. For
instance, the TCP SYN denial of service attack [TCPSYN] can be
mounted successfully without disguising the sender's address.
However, it is common security practice to disguise one's address in modern networks order to partition the
network into external and internal networks using a firewall. The
internal network
conceal one's identity if an attack is then assumed discovered.

Each protocol is susceptible to specific active attacks, but
experience shows that a number of common patterns of attack can be secure and only limited secu-
rity measures are used there.
adapted to any given protocol. The internal portion of such next sections describe a network
is often called number
of these patterns and give specific examples of them as applied to
known protocols.

3.3.1. Replay Attacks

In a WALLED GARDEN.

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 REPLAY ATTACK, the attacker records a sequence of messages off
of the wire and plays them back to be deployed in closed
environments often are later deployed on the Internet, thus creating
serious vulnerabilities.

Second, networks party which appear to be topologically disconnected may originally
received them. Note that the attacker does not be. One reason may need to be that able to
understand the network has been reconfigured messages. He merely needs to
allow access by capture and retransmit
them.

For example, consider the outside world. Moreover, firewalls are increas-
ingly passing generic application layer protocols case where an S/MIME message is being used
to request some service, such as [SOAP] a credit card purchase 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 stock
trade. An attacker might wish to systems is from
insiders, not outsiders. Since insiders by definition have access the service executed twice, if
only to inconvenience the internal network, topological protections such as firewalls will
not protect them.

5. Writing Security Considerations Sections

While it is not a requirement that any given protocol or system be
immune victim. He could capture the message and
replay it, even though he can't read it, causing the transaction to all forms of
be executed twice.

3.3.2. Message Insertion

In a MESSAGE INSERTION attack, the attacker forges a message with
some chosen set of properties and injects it is still necessary for authors into the network. Often
this message will have a forged source address in order to
consider as many forms as possible. Part disguise
the identity of the purpose attacker.

For example, a denial-of-service attack can be mounted by inserting a
series of spurious TCP SYN packets directed towards the

Rescorla, 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

Rescorla & Korver Best Current Practice [Page 24]Internet-Draft 10]

RFC 3552 Security Considerations Guidelines

Security Considerations section is to explain what attacks are out July 2003

allow some limited number of
scope connections in this "half-open" state
and what countermeasures when this limit is reached, no more connections can be applied initiated,
even from legitimate hosts. Note that this attack is a blind attack,
since the attacker does not need to defend against them. process the victim's SYNs.

3.3.3. Message Deletion

There should be a clear description of MESSAGE DELETION attack, the kinds of threats on attacker removes a message from the
described protocol or technology. This should be approached as an
effort to perform "due diligence" in describing all known or foresee-
able risks and threats
wire. Morris' sequence number guessing attack [SEQNUM] often
requires a message deletion attack to potential implementers and users.

Authors MUST describe

1. which attacks are out of scope (and why!)
2. 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 attacks are in-scope
2.1 and would tear the protocol is susceptable
illegitimate connection down. In order to
2.2 and the protocol protects against

At least prevent this host from
sending a RST so that the following forms of attack MUST can be considered: eavesdrop-
ping, replay, carried out successfully,
Morris describes flooding this host to create queue overflows such
that the SYN packet is lost and thus never responded to.

3.3.4. Message Modification

In a MESSAGE MODIFICATION attack, the attacker removes a message insertion, deletion, modification, from
the wire, modifies it, and man-in-
the-middle. Potential denial reinjects it into the network. This sort
of service attacks MUST be identified as
well. If attack is particularly useful if the protocol incorporates cryptographic protection mecha-
nisms, it should be clearly indicated which portions attacker wants to send some
of the data are
protected and what in the protections are (i.e. integrity only, confi-
dentiality, and/or endpoint authentication, etc.). Some indication
should message but also be given wants to what sorts change some of attacks it.

Consider the cryptographic pro-
tection is susceptible. Data which should be held secret (keying
material, random seeds, etc.) should be clearly labeled.

If case where the technology involves authentication, particularly user-host
authentication, attacker wants to attack an order for
goods placed over the security of Internet. He doesn't have the authentication method MUST be
clearly specified. That is, authors MUST document victim's credit
card number so he waits for the assumptions 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 security attacker cuts the credit card number out
of this authentication method is predicated upon.
For instance, in the case original message and pastes it into the new message.

Another interesting example of a cut-and-paste attack is provided by
[IPSPPROB]. If IPsec ESP is used without any MAC then it is possible
for the UNIX username/password login method, attacker to read traffic encrypted for a statement victim on the same
machine. The attacker attaches an IP header corresponding to a port
he controls onto the effect of:

Authentication in encrypted IP packet. When the system packet is secure only to
received by the extent that host it
is difficult will automatically be decrypted and forwarded
to guess or obtain a ASCII password that is the attacker's port. Similar techniques can be used to mount a maximum
session hijacking attack. Both of 8 characters long. These passwords these attacks can be obtained by sniffing
telnet sessions or avoided by running the 'crack' program
always using the con-
tents of the /etc/passwd file. Attempts to protect against on-line
password guessing by message authentication when you use encryption. Note
that this attack only works if (1) disconnecting after several unsuccessful
login attempts and (2) waiting between successive password prompts no MAC check is effective only to the extent that attackers are impatient.

Because the /etc/passwd file maps usernames to user ids, groups,
etc. it must be world readable. In order to permit being used, since
this usage but
make running crack more difficult, the file attack generates damaged packets (2) a host-to-host SA is often split into
/etc/passwd and being
used, since a 'shadow' password file. The shadow file 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 not

Rescorla, single-user than this attack is infeasible.

Rescorla & Korver Best Current Practice [Page 25]

world readable and contains 11]

RFC 3552 Security Considerations Guidelines July 2003

3.3.5. Man-In-The-Middle

A MAN-IN-THE-MIDDLE attack combines the encrypted password. The regular
/etc/passwd file contains above techniques in a dummy password special
form: The attacker subverts the communication stream in its place.

It is insufficient order 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, pose
as the protections those
services are expected sender to provide MUST be clearly specified. In addi-
tion, receiver and the resultant properties receiver to the sender:

What Alice and Bob think:
Alice <----------------------------------------------> Bob

What's happening:
Alice <----------------> Attacker <----------------> Bob

This differs fundamentally from the above forms of attack because it
attacks the combined system need to be
specified.

Note: In general, identity of the IESG will not approve standards track protocols communicating parties, rather than the
data stream itself. Consequently, many techniques which do not provide for strong authentication, either internal to
integrity of the protocol or through tight binding communications stream are insufficient to protect
against man-in-the-middle attacks.

Man-in-the-middle attacks are possible whenever a lower layer security pro-
tocol.

The threat environment addressed 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 Security Considerations sec-
tion MUST at a minimum include deployment across client's SYN before the global Internet
across multiple administrative boundaries without assuming that fire-
walls are in place, even if only server does), then the attacker can
open another connection to provide justification for why
such consideration is out of scope for the protocool. server and begin a man-in-the-middle
attack. 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 also trivial to have deployment in mount man-in-the-middle attacks on
local networks via ARP spoofing -- the global Internet. In some
cases, there might be attacker forges 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.

There should be a clear description of ARP with
the residual risk victim's IP address and his own MAC address. Tools to the user
or operator mount this
sort of attack are readily available.

Note that protocol after threat mitigation has been
deployed. Such risks might arise from compromise in a related proto-
col (e.g. IPsec it is useless if key management has been compromised),
from incorrect implementation, compromise only necessary to authenticate one side of the security technology
used for risk reduction (e.g. a cipher with
transaction in order to prevent man-in-the-middle attacks. In such a 40-bit key), or there
might be risks that are not addressed by
situation the protocol specification
(e.g. denial of service attacks on the peers can establish an underlying link protocol).

Particular care should be taken association in situations where the compromise of which only
one peer is authenticated. In such a single system would compromise system, 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 attacker can
initiate an association posing as the unauthenticated peer but cannot
transmit or access data being sent on a
certificate authority) where compromise of a single system could lead
to widespread compromises, it legitimate connection. This
is appropriate to consider systems and
physical security an acceptable situation in contexts such as well.

There should also Web e-commerce where
only the server needs to be authenticated (or the client is
independently authenticated via some discussion of potential security risks
arising from potential misapplications of non-cryptographic mechanism such
as a credit card number).

3.4. Topological Issues

In practice, the protocol or technology
described in assumption that it's equally easy for an attacker to
read and generate all packets is false, since the RFC. Internet is not
fully connected. This might be coupled with an Applicability

Rescorla, has two primary implications.

Rescorla & Korver Best Current Practice [Page 26]Internet-Draft 12]

RFC 3552 Security Considerations Guidelines

Statement July 2003

3.5. On-path versus off-path

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 RFC.

6. Examples path. This section consists of some example security considerations sec-
tions, intended makes it much
easier to give the reader mount a flavor wide variety of what's intended by
this document.

The first example is a 'retrospective' example, applying the criteria attacks if you are on-path.

Off-path hosts can, of this document 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 an existing widely deployed protocol, SMTP. The
second example place themselves on-path. This is a good security considerations section clipped from
a current protocol.

6.1. SMTP

When RFC 821 was written, Security Considerations sections were not
required in RFCs, and none by no means
impossible but is contained in not necessarily trivial.

Applications protocol designers MUST NOT assume that document. [RFC 2821]
updated RFC 821 and added a detailed security considerations section.
We reproduce here the Security Considerations section all attackers
will be off-path. Where possible, protocols SHOULD be designed to
resist attacks from that docu-
ment (with new section numbers). Our comments attackers who have complete control of the
network. However, designers are indented and pref-
aced with 'NOTE:'. We also add a number expected to give more weight to
attacks which can be mounted by off-path attackers as well as on-path
ones.

3.6. Link-local

One specialized case of new sections on-path is being on the same link. In some
situations, it's desirable to cover top-
ics we consider important. Those sections distinguish between hosts who are marked with [NEW] in on
the section header.

6.1.1. Security Considerations

6.1.1.1. Mail Security local network and Spoofing

SMTP mail those who are not. The standard technique for
this is inherently insecure in verifying the IP TTL value [IP]. Since the TTL must be
decremented by each forwarder, a protocol can demand that it is feasible for even
fairly casual users TTL be set
to negotiate directly with receiving and relaying
SMTP servers 255 and create messages that will trick a naive recipient
into believing all receivers verify the TTL. A receiver then has
some reason to believe that they came conforming packets are from somewhere else. Constructing such
a message so that the "spoofed" behavior cannot same
link. Note that this technique must be detected by used with care in the
presence of tunneling systems, since such systems may pass packets
without decrementing TTL.

4. Common Issues

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
expert is somewhat more difficult, obvious but not sufficiently so as to be insecure solution even though better solutions
are available. This section describes a
deterrent to someone who is determined and knowledgeable. Conse-
quently, as knowledge number of Internet mail increases, so does issues seen in
many protocols and the knowl-
edge common pieces of security technology that SMTP mail inherently cannot may
be authenticated, or integrity
checks provided, at the transport level. Real mail security lies only useful in end-to-end methods involving the message bodies, such as those
which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME
[31]).

Rescorla, addressing them.

Rescorla & Korver Best Current Practice [Page 27]

NOTE: One bad approach to sender authentication is [IDENT]
in 13]

RFC 3552 Security Considerations Guidelines July 2003

4.1. User Authentication

Essentially every system which the receiving mail server contacts the alleged sender
and asks wants to control access to its
resources needs some way to authenticate users. A nearly uncountable
number of such mechanisms have been designed for the this purpose. The
next several sections describe some of these techniques.

4.1.1. Username/Password

The most common access control mechanism is simple USERNAME/PASSWORD
The user provides a username of and a reusable password to the sender. host
which he wishes to use. This system is a bad idea
for a number of reasons, including but not limited vulnerable to
relaying, TCP connection hijacking, and a simple lying by
passive attack where the
origin server. Aside from attacker sniffs the fact that IDENT is of low security
value, use of IDENT by receiving sites password off the wire
and then initiates a new session, presenting the password. This
threat can lead to operational
problems. Many sending sites blackhole IDENT requests,
thus causing mail to be held until mitigated by hosting the receiving server's
IDENT request times out.

Various protocol extensions and configuration options that provide
authentication at the transport level (e.g., from an SMTP client to over an SMTP server) improve somewhat on the traditional situation
described above. However, unless they encrypted
connection such as TLS or IPSEC. Unprotected (plaintext)
username/password systems are accompanied by careful
handoffs of responsibility not acceptable 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.

Efforts to make it more difficult for users to set envelope return
path IETF standards.

4.1.2. Challenge Response and header "From" fields to point to valid addresses other than
their own are largely misguided: they frustrate legitimate applica-
tions in which mail is sent by one user on behalf of another or in One Time Passwords

Systems which error (or normal) replies should be directed to a special
address. (Systems that provide convenient ways for users to alter
these fields on desire greater security than USERNAME/PASSWORD often
employ either a per-message basis should attempt to establish ONE TIME PASSWORD [OTP] scheme or a
primary and permanent mailbox address for 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 that Sender
fields within the message data user
can be generated sensibly.)

This specification does not further address simply compute the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled next password in the hope of providing some small margin sequence.) SecureID and
DES Gold are variants of protec-
tion against an ignorant this scheme. In a challenge-response
scheme, the host and the user who share some secret (which often is trying
represented as a password). In order to fake mail.

NOTE: We have added additional material authenticate the user, the
host presents the user with a (randomly generated) challenge. The
user computes some function based on communications security the challenge and
SMTP the secret and
provides that to the host, which verifies it. Often this computation
is performed in Section 6.1.2 In a final specification, the above text
would be edited somewhat handheld device, such as a DES Gold card.

Both types of scheme provide protection against replay attack, but
often still vulnerable to reflect that fact.

6.1.1.2. Blind Copies

Addresses 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 do not appear in the message headers may appear in produces the
RCPT commands to an SMTP server for a number of reasons. The two most
common involve right output. This is
made easier if the use of shared secret is a mailing address as password, in which case he can
mount a "list exploder" (a
single address DICTIONARY ATTACK -- meaning that resolves into multiple addresses) and the appear-
ance he tries a list of "blind copies". Especially when more common
words (or strings) rather than one RCPT command just random strings.

These systems are also often vulnerable to an active attack. Unless
communication security is

Rescorla, provided for the entire session, the
attacker can simply wait until authentication has been performed and
hijack the connection.

Rescorla & Korver Best Current Practice [Page 28]Internet-Draft 14]

RFC 3552 Security Considerations Guidelines

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 July 2003

4.1.3. Shared Keys

CHALLENGE-RESPONSE type systems that are aware can be made secure against dictionary
attack by using randomly generated shared keys instead of "bcc" use MAY find it helpful to send
each blind copy as a separate message transaction containing only a
single RCPT command.

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 user-
generated passwords. If the headers. Receiving
systems SHOULD NOT attempt to deduce such relationships and use them
to alter keys are sufficiently large then
keysearch attacks become impractical. This approach works best when
the headers of keys are configured into the message for delivery. The popular "Appar-
ently-to" header is a violation of this principle as well as a common
source of unintended information disclosure and SHOULD NOT be used.

6.1.1.3. VRFY, EXPN, end nodes rather than memorized and Security

As discussed
typed in section 3.5, individual sites may want to disable
either or both by users, since users have trouble remembering sufficiently
long keys.

Like password-based systems, shared key systems suffer from
management problems. Each pair of VRFY or EXPN for security reasons. As communicating parties must have
their own agreed-upon key, which leads to there being a corollary lot of keys.

4.1.4. Key Distribution Centers

One approach to solving the above, implementations that permit this MUST NOT appear large number of keys problem is to
have verified addresses use an
online "trusted third party" that are not, in fact, verified. If a site
disables these commands for security reasons, mediates between the SMTP server MUST
return authenticating
parties. The trusted third party (generally called a 252 response, rather than a code that could be confused with
successful or unsuccessful verification.

Returning KEY
DISTRIBUTION CENTER (KDC)) shares a 250 reply code symmetric key or password with the address listed
each party in the VRFY com-
mand after having checked system. It first contacts the KDC which gives it only for syntax violates this rule. Of
course, an implementation that "supports" VRFY by always returning
550 whether or not a
TICKET containing a randomly generated symmetric key encrypted under
both peer's keys. Since only the address is valid is equally not in confor-
mance.

Within proper peers can decrypt the last few years,
symmetric key the contents of mailing lists have become ticket can be used to establish a trusted
association. By far the most popular as an address information source for so-called "spammers."
The KDC system is Kerberos
[KERBEROS].

4.1.5. Certificates

A simple approach is to have all users have CERTIFICATES [PKIX] which
they then use of EXPN to "harvest" addresses has increased authenticate in some protocol-specific way, as list adminis-
trators have installed protections against inappropriate uses in
[TLS] or [S/MIME]. A certificate is a signed credential binding an
entity's identity to its public key. The signer of the
lists themselves. Implementations SHOULD still provide support for
EXPN, but sites SHOULD carefully evaluate the tradeoffs. As authenti-
cation mechanisms are introduced into SMTP, some sites a certificate is
a CERTIFICATE AUTHORITY (CA), whose certificate may choose itself be signed
by some superior CA. In order for this system to
make EXPN available only work, trust in one
or more CAs must be established in an out-of-band fashion. Such CAs
are referred to authenticated requestors.

NOTE: It's not clear that disabling VRFY adds much protection,
since it's often possible as TRUSTED ROOTS or ROOT CAS. The primary obstacle
to discover whether an address is valid
using RCPT TO.

Rescorla, Korver [Page 29]

6.1.1.4. Information Disclosure this approach in Announcements

There has been an ongoing debate about the tradeoffs between the
debugging advantages of announcing server client-server type and version (and,
sometimes, even server domain name) in systems is that it requires
clients to have certificates, which can be a deployment problem.

4.1.6. Some Uncommon Systems

There are ways to do a better job than the greeting response or in
response schemes mentioned above,
but they typically don't add much security unless communications
security (at least message integrity) will be employed to secure the HELP command and
connection, because otherwise the disadvantages attacker can merely hijack the
connection after authentication has been performed. A number of exposing infor-
mation that might
protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap a

Rescorla & Korver Best Current Practice [Page 15]

RFC 3552 Security Considerations Guidelines July 2003

user's password into a shared key which can be useful in used as input to a potential hostile attack. The util-
ity of
cryptographic protocol. One major obstacle to the debugging information is beyond doubt. Those who argue for
making it available point out deployment of
these protocols has been that it their Intellectual Property status is far better to actually
secure an SMTP server rather than hope that trying to conceal known
vulnerabilities by hiding
extremely unclear. Similarly, the server's precise identity will provide
more protection. Sites user can authenticate using public
key certificates (e.g., S-HTTP client authentication). Typically
these methods are encouraged to evaluate used as part of a more complete security protocol.

4.1.7. Host Authentication

Host authentication presents a special problem. Quite commonly, the tradeoff with
that issue in mind; implementations
addresses of services are strongly encouraged to mini-
mally provide presented using a DNS hostname, for making type and version information available in
some way to other network hosts.

6.1.1.5. Information Disclosure in Trace Fields

In some circumstances,
instance as a URL [URL]. When requesting such as when mail originates from within a LAN
whose hosts are not directly on service, one has to
ensure that the public Internet, trace
("Received") fields produced in conformance with this specification
may disclose host names and similar information entity that would not nor-
mally be available. This ordinarily does one is talking to not pose only has a problem,
certificate but
sites with special concerns about name disclosure should be aware that that certificate corresponds to the expected
identity of
it. Also, the optional FOR clause should be supplied with caution or
not at all when multiple recipients are involved lest server. The important thing to have is a secure
binding between the certificate and the expected hostname.

For instance, it inadver-
tently disclose is usually not acceptable for the identities of "blind copy" recipients certificate to others.

6.1.1.6. Information Disclosure in Message Forwarding

As discussed
contain an identity in section 3.4, use the form of an IP address if the 251 or 551 reply codes 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.

4.2. Generic Security Frameworks

Providing security functionality in a protocol can be difficult. In
addition to
identify the replacement address associated with problem of choosing authentication and key
establishment mechanisms, one needs to integrate it into a mailbox may inad-
vertently disclose sensitive information. Sites that are concerned
about those issues should ensure that they select protocol.
One response to this problem (embodied in IPsec and configure
servers appropriately.

6.1.1.7. Scope of Operation of SMTP Servers

It TLS) is to create
a well-established principle lower-level security protocol and then insist that an SMTP server may refuse new protocols be
run over that protocol. Another approach that has recently become
popular is to
accept mail for any operational or technical reason design generic application layer security frameworks.
The idea is that makes sense you design a protocol that allows you to the site providing the server. However, cooperation among sites
and installations makes the Internet possible. If sites take exces-
sive advantage of the right negotiate
various security mechanisms in a pluggable fashion. Application
protocol designers then arrange to reject traffic, carry the ubiquity security protocol PDUs
in their application protocol. Examples of email
availability (one such frameworks include
GSS-API [GSS] and SASL [SASL].

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 strengths of negotiation in order to force the Internet) will be threat-
ened; considerable care should be taken and balance maintained if a
site decides
parties to be selective about negotiate weaker protection than they otherwise would.
It's possible to include an integrity check after the traffic it will accept negotiation and
process.

Rescorla, Korver [Page 30]Internet-Draft Security Considerations Guidelines

In recent years, use of
key establishment have both completed, but the relay function through arbitrary sites
has been used as part strength of hostile efforts this
integrity check is necessarily limited to hide the actual origins
of mail. Some sites have decided weakest common
algorithm. This problem exists with any negotiation approach, but

Rescorla & Korver Best Current Practice [Page 16]

RFC 3552 Security Considerations Guidelines July 2003

generic frameworks exacerbate it by encouraging the application
protocol author to limit just specify the use of framework rather than think hard
about the relay func-
tion to known or identifiable sources, and implementations SHOULD
provide appropriate underlying mechanisms, particularly since the capability to perform this type
mechanisms can very widely in the degree of filtering. When mail security offered.

Another problem is rejected for these or other policy reasons, a 550 code SHOULD 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 in response to EHLO, MAIL, or RCPT merely as appropriate.

6.1.1.8. Inappropriate Usage [NEW]

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 an
authentication framework -- in which case the SASL exchange occurs
but the rest of the connection is spam or not. From unprotected, but can also negotiate
traffic protection, such as via GSS, as a protocol per-
spective, spam is indistinguishable from other e-mail--the distinc-
tion mechanism. Knowing under
what circumstances traffic protection is almost entirely social optional and often quite subtle. (For instance, which it is a message from a merchant from whom you've purchased items before
advertising similar items spam?) SMTP spam-suppression mechanisms
required requires thinking about the threat model.

In general, authentication frameworks are
generally limited most useful in situations
where new protocols are being added to identifying known spam senders and either refus-
ing systems with pre-existing
legacy authentication systems. A framework allows new installations
to service them or target them for punishment/disconnection.
[RFC-2505] provides extensive guidance on making SMTP servers spam-
resistant. We provide better authentication while not forcing existing sites
completely redo their legacy authentication systems. When the
security requirements of a brief discussion system can be clearly identified and only
a few forms of the topic here.

The primary tool for refusal authentication are used, choosing a single security
mechanism leads to service spammers greater simplicity and predictability. In
situations where a framework is to be used, designers SHOULD
carefully examine the blacklist.
Some authority such as [MAPS] collects framework's options and publishes specify only the
mechanisms that are appropriate for their particular threat model.
If a list framework is necessary, designers SHOULD choose one of known
spammers. Individual SMTP servers then block the blacklisted offend-
ers (generally by IP address).

In order to avoid being blacklisted or otherwise identified, spammers
often attempt to obscure
established ones instead of designing their identity, either own.

4.3. Non-repudiation

The naive approach to non-repudiation is 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 [ORBS] of open
relays as well.

6.1.1.8.1. Closed Relaying [NEW]

To avoid being used for spam forwarding, many SMTP servers operate as
closed relays, providing relaying service only for clients to use public-key
digital signatures over the content. The party who they wishes to be
bound (the SIGNING PARTY) digitally signs the message in question.
The counterparty (the RELYING PARTY) can identify. Such relays should generally insist later point to the digital
signature as proof that senders adver-
tise a sending address consistent with their known identity. If the
relay signing party at one point agreed to the
disputed message. Unfortunately, this approach is providing service insufficient.

The easiest way for an identifiable network (such as a
corporate network or an ISP's network) then it is sufficient the signing party to block
all other IP addresses.) 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 other cases, explicit authentication must
be used. The two standard choices for order to defend against this are TLS [STARTTLS] 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
SASL [SASLSMTP].

Rescorla, timestamp servers to establish the time that the
message was signed.

Rescorla & Korver Best Current Practice [Page 31]

6.1.1.8.2. Endpoints [NEW]

Realistically, SMTP endpoints cannot refuse to deny service to unau-
thenticated senders. Since 17]

RFC 3552 Security Considerations Guidelines July 2003

Additionally, the vast majority of senders are unauthen-
ticated, this would break Internet mail interoperability. The excep-
tion relying party might attempt to this trick the signing
party into signing one message while thinking he's signing another.
This problem is particularly severe 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 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 public gateway smartcard but
configure its internal servers to only talk to the gateway.

6.1.2. Communications security issues

SMTP itself provides no communications security, and therefore a
large number of attacks are possible. A passive attack is sufficient message to recover the text of messages transmitted with SMTP. No endpoint
authentication be signed is provided displayed by
the protocol. Sender spoofing is triv-
ial, and therefore forging email messages is trivial. Some implemen-
tations do add header lines with hostnames derived through reverse
name resolution (which is only secure relying party.

All of these complications make non-repudiation a difficult service
to deploy in practice.

4.4. Authorization vs. Authentication

AUTHORIZATION is the extent that process by which one determines whether an
authenticated party has permission to access a particular resource or
service. Although tightly bound, it is diffi-
cult important to spoof DNS -- not very), although these header lines realize that
authentication and authorization are nor-
mally 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.

Authorization necessarily relies on authentication, but
authentication alone does not displayed imply authorization. Rather, before
granting permission to users. Receiver spoofing is also fairly
straight-forward, either using TCP connection hijacking or DNS spoof-
ing. Moreover, since email messages often pass through SMTP gateways,
all intermediate gateways perform an action, the authorization mechanism
must be trusted, consulted to determine whether that action is permitted.

4.4.1. Access Control Lists

One common form of authorization mechanism is an access control list
(ACL), which lists users that are permitted access to a condition nearly impos-
sible on the global Internet.

Several approaches resource.
Since assigning individual authorization permissions to each resource
is tedious, resources are available for alleviating these threats. In
order of increasingly high often hierarchically arranged so that the
parent resource's ACL is inherited by child resources. This allows
administrators to set top level in policies and override them when
necessary.

4.4.2. Certificate Based Systems

While the protocol stack, we have:

SMTP over IPSEC
SMTP/TLS
S/MIME distinction between authentication and PGP/MIME

6.1.2.1. SMTP over IPSEC [NEW]

An SMTP connection run over IPSEC can provide confidentiality for authorization is
intuitive when using simple authentication mechanisms such as
username and password (i.e., everyone understands the
message difference
between the sender administrator account and a user account), with more
complex authentication mechanisms the first hop SMTP gateway, or between
any pair of connected SMTP gateways. That distinction is to say, it provides
channel security sometimes lost.

With certificates, for the SMTP connections. In instance, presenting a situation where the
message goes directly from the client to the receiver's gateway, this
may provide substantial security (though the receiver valid signature does
not imply authorization. The signature must still
trust the gateway). Protection is provided against replay attacks,
since the data itself is protected and the packets cannot be
replayed.

Endpoint identification is backed by a problem, however, unless the receiver's
address can
certificate chain that contains a trusted root, and that root must be directly cryptographically authenticated. Sender

Rescorla,

Rescorla & Korver Best Current Practice [Page 32]Internet-Draft 18]

RFC 3552 Security Considerations Guidelines

identification is not generally available, since generally only the
sender's machine is authenticated, not the sender himself. Further-
more, the identity of the sender simply appears July 2003

trusted in the From header of given context. For instance, users who possess
certificates issued by the message, so it is easily spoofable Acme MIS CA may have different web access
privileges than users who possess certificates issued by the sender. Finally, unless Acme
Accounting CA, even though both of these CAs are "trusted" by the security policy is set extremely strictly, there
Acme web server.

Mechanisms for enforcing these more complicated properties have not
yet been completely explored. One approach is also an
active downgrade simply to cleartext attack. attach
policies to ACLs describing what sorts of certificates are trusted.
Another problem approach is to carry that information with IPsec the certificate,
either as a security solution certificate extension/attribute [PKIX, SPKI] or as a
separate "Attribute Certificate".

4.5. Providing Traffic Security

Securely designed protocols should provide some mechanism for SMTP
securing (meaning integrity protecting, authenticating, and possibly
encrypting) all sensitive traffic. One approach is the
lack of a standard IPsec API. In order to take advantage of IPsec,
applications in general need to be able to instruct secure the IPsec imple-
mentation about their security policies and discover what protection
has been applied to their connections. Without a standard API
protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this
provides security which is
very difficult to do portably.

Implementors of SMTP servers or SMTP administarors MUST NOT assume
that IPsec will be available unless they have reason most fitted to believe that
it will be (such as the existence of preexisting association between
two machines). However, protocol, it may be a reasonable procedure to attempt also
requires considerable effort to create an get right.

Many protocols can be adequately secured using one of the available
channel security systems. We'll discuss the two most common, IPsec association opportunistically to a peer server
when mail is delivered. Note that in cases where
[AH, ESP] and [TLS].

4.5.1. IPsec is used to

The IPsec protocols (specifically, AH and ESP) can provide a VPN tunnel
transmission security for all traffic between two sites, this is hosts. The IPsec
protocols support varying granularities of substantial secu-
rity value, particularly to the extent that confidentiality is pro-
vided, subject to the caveats mentioned above. Also see [USEIPSEC] user identification,
including for general guidance on the applicability example "IP Subnet", "IP Address", "Fully Qualified
Domain Name", and individual user ("Mailbox name"). These varying
levels of IPsec.

6.1.2.2. SMTP/TLS [NEW]

SMTP can be combined with TLS identification are employed as described in [STARTTLS]. This pro-
vides similar protection inputs to access control
facilities 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 are an intrinsic part of TLS con-
tain IPsec. However, a US exportable (and hence low security) mode. Applications
desiring high given
IPsec implementation might not support all identity types. In
particular, security should ensure gateways may not provide user-to-user
authentication or have mechanisms to provide that this mode is disabled. Pro-
tection authentication
information to applications.

When AH or ESP is provided against replay attacks, since used, the data itself is
protected and 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 packets cannot be replayed. [note: The AH or ESP implementation being used.
Unfortunately, APIs for controlling IPsec implementations are not yet
standardized.

Rescorla & Korver Best Current Practice [Page 19]

RFC 3552 Security Considerations section Guidelines July 2003

The primary obstacle to using IPsec to secure other protocols is
deployment. The major use of the SMTP over TLS draft IPsec at present is quite good for VPN
applications, especially for remote network access. Without
extremely tight coordination between security administrators and
bears reading as an example of how
application developers, VPN usage is not well suited to do things.]

6.1.2.3. S/MIME and PGP/MIME [NEW]

S/MIME and PGP/MIME are both message oriented security protocols.
They provide object providing
security services for individual messages. With various
settings, sender and recipient authentication and confidentiality may
be applications since it is difficult
for such applications to determine what security services have in
fact been provided. More importantly,

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 identification is not of operating system, either by
modifying with the send-
ing and receiving machines, but rather kernel or installing new drivers. This is a
substantially greater undertaking than simply installing a new
application. However, recent versions of the sender and recipient
themselves. (Or, at least, a number of cryptographic keys corresponding commodity
operating systems include IPsec stacks, so deployment is becoming
easier.

In environments where IPsec is sure to be available, it represents a
viable option for protecting application communications traffic. If
the
sender traffic to be protected is UDP, IPsec and recipient.) Consequently, end-to-end application-specific
object security are the only options. However, designers MUST NOT
assume that IPsec will be available. A security may be

Rescorla, Korver [Page 33]

obtained. Note, however, policy for a generic
application layer protocol SHOULD NOT simply state that no protection IPsec must be
used, unless there is provided against
replay attacks. Note also some reason to believe that S/MIME and PGP/MIME generally provide
identifying marks for both sender IPsec will be
available in the intended deployment environment. In environments
where IPsec may not be available and receiver. Thus even when confi-
dentiality is provided, the traffic analysis is still possible.

6.1.3. Denial of Service

None of these security measures provides any real protection against
denial solely TCP, TLS
is the method of service. SMTP connections choice, since the application developer can easily be used to tie up sys-
tem resources in
ensure its presence by including a number TLS implementation in his package.

In the special-case of ways, including excessive port consump-
tion, excessive disk usage (email is typically delivered to disk
files), and excessive memory consumption (sendmail, for instance, is
fairly large, IPv6, both AH and typically forks a new process ESP are mandatory to deal with each
message.)

If transport- or application-layer security is used for SMTP connec-
tions,
implement. Hence, it is possible reasonable to mount a variety of attacks on individual
connections using forged RSTs or other kinds of packet injection.

6.2. VRRP

The second example is from VRRP, the Virtual Router Redundance Proto-
col ( [VRRP] ). We reproduce here the Security Considerations section
from assume that document (with new section numbers). Our comments AH/ESP are
indented and prefaced with 'NOTE:'.

6.2.1. Security Considerations

VRRP is designed 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. [USEIPSEC]
provides quite a range bit 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 guidance on each approach including possible
attacks and recommended environments follows.

Independent of any authentication type VRRP includes when IPsec is a mechanism
(setting TTL=255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits good choice.

4.5.2. SSL/TLS

Currently, the most
vulnerabilities common approach is to local attacks.

NOTE: The use SSL or its successor
TLS. They provide channel security measures discussed in for a TCP connection at the following sections
only
application level. That is, they run over TCP. SSL implementations
typically provide various kinds of authentication. No confidentiality a Berkeley Sockets-like interface for easy
programming. The primary issue when designing a protocol solution
around TLS is provided at all. This should be explicitly described as outside
the scope.

Rescorla, to differentiate between connections protected using
TLS and those which are not.

Rescorla & Korver Best Current Practice [Page 34]Internet-Draft 20]

RFC 3552 Security Considerations Guidelines

6.2.1.1. No Authentication July 2003

The use of this authentication type means two primary approaches used have a separate well-known port for
TLS connections (e.g., the HTTP over TLS port is 443) [HTTPTLS] or to
have a mechanism for negotiating upward from the base protocol to TLS
as in [UPGRADE] or [STARTTLS]. 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.

Note that VRRP TLS depends upon a reliable protocol
exchanges are not authenticated. such as TCP or SCTP.
This type of authentication SHOULD
only produces two notable difficulties. First, it cannot be used in environments were there is minimal security risk and
little chance for configuration errors (e.g., two VRRP routers on a
LAN).

6.2.1.2. Simple Text Password

The use of this authentication type means to
secure datagram protocols that VRRP protocol
exchanges are authenticated by a simple clear text password.

This type of authentication use UDP. Second, TLS is useful susceptible
to protect against accidental
misconfiguration IP layer attacks that IPsec is not. Typically, these attacks take
some form 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 denial 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 service or connection assassination. For
instance, an attacker might forge a VRRP packet TCP RST to be sent from
another LAN shut down SSL
connections. TLS has mechanisms to disrupt VRRP operation.

This type of authentication is RECOMMENDED when there detect truncation attacks but
these merely allow the victim to know he is minimal risk being attacked and do not
provide connection survivability in the face of nodes 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 LAN actively disrupting VRRP operation. concern, then AH/ESP
or the TCP MD5 option [TCPMD5] are the preferred choices.

4.5.2.1. Virtual Hosts

If this type of
authentication is used the user should be aware that this clear text
password "separate ports" approach to TLS is sent frequently, and therefore should not used, then TLS will be the same as
negotiated before any security significant password.

NOTE: This section should be clearer. The basic point application-layer traffic is that no
authentication and Simple Text are only useful for sent. This can
cause a very limited
threat model, namely problem with protocols that none of the nodes on the local LAN are
hostile. The TTL check prevents hostile nodes off-LAN from posing use virtual hosts, such 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:
[HTTP], since the compromise
of any node server does not know which certificate to offer the LAN allows reconfiguration of
client during the VRRP nodes.

6.2.1.3. IP Authentication Header TLS handshake. The use of TLS hostname extension [TLSEXT]
can be used to solve this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP Authentica-
tion Header [AH] using [HMAC]. This provides strong protection
against configuration errors, replay attacks, and packet corrup-
tion/modification.

Rescorla, Korver [Page 35]

This type of authentication problem, although it is RECOMMENDED when there too new to have
seen wide deployment.

4.5.2.2. Remote Authentication and TLS

One difficulty with using TLS is limited con-
trol over that the administration of nodes on server is authenticated via
a LAN. While this type of
authentication does protect certificate. This can be inconvenient in environments where
previously the operation of VRRP, there are other
types only form of attacks that may be employed on authentication was a password shared media links (e.g.,
generation of bogus ARP replies) which are independent from VRRP
between client and
are not protected.

NOTE: server. It's a mistake tempting to have AH be use TLS without an
authenticated server (i.e., with anonymous DH or a RECOMMENDED in self-signed RSA
certificate) and then authenticate via some challenge-response
mechanism such as SASL with CRAM-MD5.

Unfortunately, this context.
Since AH 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 only mechanism SASL
handshake. From then on, it's as if the connection were in the

Rescorla & Korver Best Current Practice [Page 21]

RFC 3552 Security Considerations Guidelines July 2003

clear, at least as far as that protects VRRP against attack
from other nodes on attacker is concerned. In order to
prevent this attack, the same LAN, it should be client needs to verify the server's
certificate.

However, if the server is authenticated, challenge-response becomes
less desirable. If you already have a MUST for cases
where there hardened channel then simple
passwords are untrusted nodes on the same network. fine. In any case,
AH should fact, they're arguably superior to
challenge-response since they do not require that the password be a MUST implement.

NOTE: There's an important piece of security analysis that's only
hinted at
stored in this document, namely the cost/benefit tradeooff clear on the server. Thus, compromise of VRRP
authentication.

The threat the key file
with challenge-response systems is more serious than if simple
passwords were used.

Note that VRRP if the client has a certificate than SSL-based client
authentication is intended to prevent is an
attacker arranging to can be used. To make this easier, SASL provides the VRRP master. This would be done by
joining
EXTERNAL mechanism, whereby the group (probably multiple times), gagging SASL client can tell the master and
then electing oneself master. Such a node could then direct traffic in
arbitrary undesirable ways.

However, it server
"examine the outer channel for my identity". Obviously, this is not necessary for an attacker to be the VRRP master to
do this. An attacker can do similar kinds of damage
subject to the network by
forging ARP packets or (on switched networks) fooling the switch VRRP
authentication offers no real protection against these attacks.

Unfortunately, authentication makes VRRP networks very brittle layering attacks described above.

4.5.3. Remote Login

In some special cases it may be worth providing channel-level
security directly in the
face of misconfiguration. Consider what happens if two nodes application rather than using IPSEC or
SSL/TLS. One such case is remote terminal security. Characters are
configured with different passwords. Each will reject messages
typically delivered from
the other client to server one character at a time.
Since SSL/TLS and therefore both will attempt AH/ESP authenticate and encrypt every packet, this
can mean a data expansion of 20-fold. The telnet encryption option
[ENCOPT] prevents this expansion by foregoing message integrity.

When using remote terminal service, it's often desirable to be master. This creates
substantial network instability.

This set securely
perform other sorts of cost/benefit tradeoffs suggests that VRRP authentication
is a bad idea, since the incremental security benefit is marginal but communications services. In addition to
providing remote login, SSH [SSH] also provides secure port
forwarding for arbitrary TCP ports, thus allowing users run arbitrary
TCP-based applications over the incremental risk is high. This judgment should SSH channel. Note that SSH Port
Forwarding can be revisited security issue if it is used improperly to
circumvent firewall and improperly expose insecure internal
applications to the
current set outside world.

4.6. Denial of non-VRRP threats Service Attacks and Countermeasures

Denial of service attacks are removed.

Acknowledgments

This document all too frequently viewed as an fact of
life. One problem is 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 an attacker can often choose from Ran's original document, one of
many denial of service attacks to inflict upon a victim, and
some because
most of these attacks cannot be thwarted, common wisdom frequently
assumes that text was taken from an email message written by Fred
Baker. The other primary source for this document there is specific

Rescorla, 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.

Rescorla & Korver Best Current Practice [Page 36]Internet-Draft 22]

RFC 3552 Security Considerations Guidelines

comments received from Steve Bellovin. Early review of this 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.

Normative References
[AH] Kent, S., and Atkinson, R., "IP Authentication Header",
RFC 2402, November 1998.

[DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.

[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946,
September, 2000.

[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.

[GSS] Linn, J., "Generic Security Services Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., Berners-Lee, T., "HyperText Transfer Protocol",
RFC 2616, June 1999.

[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.

[HMAC] Madsen, C., Glenn, R., "The Use July 2003

However, not all denial of HMAC-MD5-96 within
ESP service attacks are equal and AH", RFC 2403, November 1998.

KERBEROS] Kohl, J., Neuman, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.

[KEYWORDS] Bradner, S., "Key words for use in RFCs more
importantly, it is possible to Indicate
Requirement Levels", RFC 2119, March 1997.

[OTP] Haller, N., Metz, C., Nesser, P., "A One-Time Password
System", Straw, M., RFC 2289, February 1998.

[PHOTURIS] Karn, P., and Simpson, W., "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.

[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., Internet X.509
"Public Key Infrastructure Certificate design protocols so that denial of
service attacks are made more difficult, if not impractical. Recent
SYN flood attacks [TCPSYN] demonstrate both of these properties: SYN
flood attacks are so easy, anonymous, and CRL Profile",
RFC 2459, January 1999.

[RFC-2223] Postel J., effective that they are
more attractive to attackers than other attacks; and Reynolds J., "Instructions because the
design of TCP enables this attack.

Because complete DoS protection is so difficult, security against DoS
must be dealt with pragmatically. In particular, some attacks which
would be desirable to RFC Authors",

Rescorla, Korver [Page 37]

RFC 2223, October 1997.

[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
RFC 2505, February 1999.

[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.

[SASL] Myers, J., "Simple Authenticatin 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 Security Layer (SASL)",
RFC 2222, October 1997.

[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
Ylonen, T., "SPKI Certificate Theory", RFC 2693,
September 1999.

[SSH] Ylonen, T., "SSH - Secure Login Connections Over cost of defense change as technology
changes and therefore so does the Internet",
6th USENIX Security Symposium, p. 37-42, July 1996.

[SASLSMTP] Myers, J., "SMTP set of attacks which should be
defended against.

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.

4.6.1. Blind Denial of Service Extension

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 Authentication",
RFC 2554, March 1999.

[STARTTLS] Hoffman, P., "SMTP 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.

4.6.2. Distributed Denial of Service Extension

Even more dangerous are DISTRIBUTED denial of service attacks (DDoS)
[DDOS]. In a DDoS the attacker arranges for Secure SMTP over TLS",
RFC 2487, January 1998.

[S-HTTP] Rescorla, E., and Schiffman, A., "The Secure HyperText Transfer
Protocol", RFC 2660, August 1999.

[S/MIME] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.

[TELNET] Postel, J., 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 Reynolds, J., "Telnet Protocol Specification",
RFC 854, May 1983.

[TLS] Dierks, T., 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 Allen, C., "The TLS Protocol Version 1.0",

Rescorla & Korver Best Current Practice [Page 23]

RFC 2246, January 1999.

[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
"Transport Layer 3552 Security (TLS) Extensions",
draft-ietf-tls-extensions-05.txt.
[NORMATIVE DEPENDENCY].

[TCPSYN] "TCP SYN Flooding and IP Spoofing Attacks",
CERT Advisory CA-1996-21, 19 September 1996, CERT.
http://www.cert.org/advisories/CA-1996-21.html

[UPGRADE] Khare, R., Lawrence, S., "Upgrading Considerations Guidelines July 2003

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.

4.6.3. Avoiding Denial of Service

There are two common approaches to making denial of service attacks
more difficult:

4.6.3.1. Make your attacker do more work than you do

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 [TCPSYN].

4.6.3.2. Make your attacker prove they can receive data from you

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 TLS Within HTTP/1.1",
RFC 2817, May 2000.

Rescorla, Korver [Page 38]Internet-Draft Security Considerations Guidelines

[URL] Berners-Lee, T., Masinter, M., McCahill, M., "Uniform Resource
Locators (URL)", RFC 1738, December 1994.

[VRRP] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt,
P., Higginson, P., Shand, M., Lindemn, A., "Virtual Router
Redundancy Protocol", RFC 2338, April 1998.

Informative References
[DDOS] "Denial-Of-Service Tools" CERT Advisory CA-1999-17,
28 December 1999, CERT
http://www.cert.org/advisories/CA-1999-17.html

[EKE] Bellovin, S., Merritt, M., "Encrypted Key Exchange:
Password-based protocols secure against dictionary
attacks", Proceedings of track)
or to forge an address which will be routed back along a path that
traverses the IEEE Symposium host from which the attack is being launched.

Hosts on Research small subnets are thus useless to the attacker (at least in Security and Privacy, May 1992.

[IDENT] St. Johns, M., "Identification Protocol", RFC 1414,
February 1993.

[INTAUTH] Haller, N., Atkinson, R., "On Internet Authentication",
RFC 1704, October 1994.

[IPSPPROB] Bellovin, S. M., "Problem Areas
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.

4.6.4. Example: TCP SYN Floods

TCP/IP is vulnerable to SYN flood attacks (which are described in
section 3.3.2) 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 IP Security Protocols",
Proceedings of
attacker can perform this action without ever having received data
from the Sixth Usenix UNIX victim, the attack can be performed anonymously (and
therefore using a large number of forged source addresses).

Rescorla & Korver Best Current Practice [Page 24]

RFC 3552 Security Symposium, Considerations Guidelines July 1996.

[KLEIN] Klein, D.V., "Foiling 2003

4.6.5. Example: Photuris

[PHOTURIS] specifies an anti-clogging mechanism that prevents attacks
on Photuris that resemble the Cracker: A Survey of and
Improvements SYN flood attack. Photuris employs a
time-variant secret to generate a "cookie" which is returned to Password Security", 1990.

[NNTP] Kantor, B, and Lapsley, P., "Network News Transfer Protocol",
RFC 977, February 1986.

[POP] Myers, J., and Rose, M., "Post Office Protocol - Version 3",
RFC 1939, May 1996.

[SEQNUM] Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP Software",
AT&T Bell Laboratories, CSTR 117, 1985.

[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D.,
"Simple Object Access Protocol (SOAP) 1.1",
May 2000.

[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange",
Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5,
pp. 5-26, October 1996.

Rescorla, Korver [Page 39]

[SRP] Wu T., "The Secure Remote Password Protocol", ISOC NDSS
Symposium, 1998.

[USEIPSEC] Bellovin, S., "Guidelines
attacker. This cookie must be returned in subsequent messages for Mandating
the Use of IPsec",
draft-bellovin-useipsec-00.txt, October 2002.
[Note to RFC editor: I understand 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 this is going he can receive packets from the victim.

4.7. Object vs. Channel Security

It's useful to
be submitted make the conceptual distinction between object
security and channel security. Object security refers to security
measures which apply to BCP Real Soon Now.]

[WEP] Borisov, N., Goldberg, I., Wagner, D., "Intercepting Mobile
Communications: The Insecurity of 802.11",
http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf

Security Considerations

This entire document is about data objects. Channel security considerations.

Author's Address
Eric Rescorla <ekr@rtfm.com>
RTFM, Inc.
2439 Alvin Drive
Mountain View, CA 94043
Phone: (650)-320-8549

Brian Korver <bkorver@xythos.com>
Xythos Software
77 Maiden Lane, Suite 200
San Francisco, CA, USA
Phone: (415)-248-3800

Internet Architecture Board <iab@iab.org>
IAB

Appendix A. IAB Members at
measures provide a secure channel over which objects may be carried
transparently but the time of this writing

Harald Alvestrand
Ran Atkinson
Rob Austein
Fred Baker
Leslie Daigle
Steve Deering
Sally Floyd
Ted Hardie
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Mike St. Johns

Rescorla, Korver [Page 40]Internet-Draft Security Considerations Guidelines

Table channel has no special knowledge about object
boundaries.

Consider the case of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Goals 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 Security . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Communication Security . . . . . . . . . . . . . . . . . . . . 2
2.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.3. Peer Entity
messages generally merely means authentication . . . . . . . . . . . . . . . . . 3
2.2. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Systems 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.

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.

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.

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

Rescorla & Korver Best Current Practice [Page 25]

RFC 3552 Security . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.1. Unauthorized Usage . . . . . . . . . . . . . . . . . . . . . 4
2.3.2. Inappropriate Usage . . . . . . . . . . . . . . . . . . . . . 4
2.3.3. Denial Considerations Guidelines July 2003

numerous inline images). Thus, from the perspective of Service . . . . . . . . . . . . . . . . . . . . . . 5
3. 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.

4.8. Firewalls and Network Topology

It's common security practice in modern networks to partition the
network into external and internal networks using a firewall. The Internet Threat Model . . . . . . . . . . . . . . . . . . . . 5
3.1. Limited Threat Models . . . . . . . . . . . . . . . . . . . . . 6
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Confidentiality Violations . . . . . . . . . . . . . . . . . 7
3.2.2. Password Sniffing . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Offline Cryptographic Attacks . . . . . . . . . . . . . . . . 7
3.3. Active Attacks . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . .
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.

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.

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
[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.

5. Writing Security Considerations Sections

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.
In

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.

Rescorla & Korver Best Current Practice [Page 26]

RFC 3552 Security Considerations Guidelines July 2003

Authors MUST describe

1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against

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.

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:

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
3.3.2. Message Insertion . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Message Deletion . . . . . . . . . . . . . . . . . . . . . . 9
3.3.4. 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.

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.

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

Rescorla & Korver Best Current Practice [Page 27]

RFC 3552 Security Considerations Guidelines July 2003

services are expected to provide MUST be clearly specified. In
addition, the resultant properties of the combined system need to be
specified.

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.

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.

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.

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.

6. Examples

This section consists of some example security considerations
sections, intended to give the reader a flavor of what's intended by
this document.

Rescorla & Korver Best Current Practice [Page 28]

RFC 3552 Security Considerations Guidelines July 2003

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.

6.1. SMTP

When RFC 821 was written, Security Considerations sections were not
required in RFCs, and none is contained in that document. [RFC 2821]
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.

6.1.1. Security Considerations

6.1.1.1. Mail Security and Spoofing

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 [14] and,
e.g., PGP [4] or S/MIME [31]).

NOTE: One bad approach to sender authentication is [IDENT] 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.

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

Rescorla & Korver Best Current Practice [Page 29]

RFC 3552 Security Considerations Guidelines July 2003

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.

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.)

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.

NOTE: We have added additional material on communications security
and SMTP in Section 6.1.2 In a final specification, the above text
would be edited somewhat to reflect that fact.

6.1.1.2. Blind Copies

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.

Rescorla & Korver Best Current Practice [Page 30]

RFC 3552 Security Considerations Guidelines July 2003

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.

6.1.1.3. VRFY, EXPN, and Security

As discussed in section 3.5, 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.

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.

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.

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.

6.1.1.4. Information Disclosure in Announcements

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

Rescorla & Korver Best Current Practice [Page 31]

RFC 3552 Security Considerations Guidelines July 2003

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.

6.1.1.5. Information Disclosure in Trace Fields

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.

6.1.1.6. Information Disclosure in Message Modification . . . . . . . . . . . . . . . . . . . . 9
3.3.5. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Topological Issues . . . . . . . . . . . . . . . . . . . . . . 11
3.5. On-path versus off-path . . . . . . . . . . . . . . . . . . . . 11
3.6. Link-local . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Common Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. User Authentication . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Username/Password . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Challenge Response Forwarding

As discussed in section 3.4, 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.

6.1.1.7. Scope of Operation of SMTP Servers

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.

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.

Rescorla & Korver Best Current Practice [Page 32]

RFC 3552 Security Considerations Guidelines July 2003

6.1.1.8. Inappropriate Usage [NEW]

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. [RFC-2505] provides extensive guidance on
making SMTP servers spam-resistant. We provide a brief discussion of
the topic here.

The primary tool for refusal to service spammers is the blacklist.
Some authority such as [MAPS] collects and publishes a list of known
spammers. Individual SMTP servers then block the blacklisted
offenders (generally by IP address).

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 [ORBS] of open relays as
well.

6.1.1.8.1. Closed Relaying [NEW]

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 [STARTTLS]
and SASL [SASLSMTP].

6.1.1.8.2. Endpoints [NEW]

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

Rescorla & Korver Best Current Practice [Page 33]

RFC 3552 Security Considerations Guidelines July 2003

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.

6.1.2. Communications security issues [NEW]

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.

Several approaches are available for alleviating these threats. In
order of increasingly high level in the protocol stack, we have:

SMTP over IPSEC
SMTP/TLS
S/MIME and PGP/MIME

6.1.2.1. SMTP over IPSEC [NEW]

An SMTP connection run over IPSEC can provide confidentiality for the
message between the sender and One Time Passwords . . . . . . . . . . 12
4.1.3. Shared Keys . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Key Distribution Centers . . . . . . . . . . . . . . . . . . 13
4.1.5. Certificates . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.6. Some Uncommon Systems . . . . . . . . . . . . . . . . . . . . 14
4.1.7. Host Authentication . . . . . . . . . . . . . . . . . . . . . 14
4.2. Generic 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.

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.

Rescorla & Korver Best Current Practice [Page 34]

RFC 3552 Security Considerations Guidelines July 2003

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.

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] for general guidance on the applicability of IPsec.

6.1.2.2. SMTP/TLS [NEW]

SMTP can be combined with TLS as described in [STARTTLS]. 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 Frameworks . . . . . . . . . . . . . . . . . . 14
4.3. Non-repudiation . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Authorization vs. Authentication . . . . . . . . . . . . . . . 16
4.4.1. Access Control Lists . . . . . . . . . . . . . . . . . . . . 17
4.4.2. Certificate Based Systems . . . . . . . . . . . . . . . . . . 17
4.5. Providing Traffic Considerations section of the SMTP over TLS document is
quite good and bears reading as an example of how to do things.]

6.1.2.3. S/MIME and PGP/MIME [NEW]

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.

Rescorla & Korver Best Current Practice [Page 35]

RFC 3552 Security . . . . . . . . . . . . . . . . . . 17
4.5.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.2. SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.2.1. Virtual Hosts . . . . . . . . . . . . . . . . . . . . . . . 19

Rescorla, Considerations Guidelines July 2003

6.1.3. Denial of Service [NEW]

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.)

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.

6.2. VRRP

The second example is from VRRP, the Virtual Router Redundance
Protocol ([VRRP]). We reproduce here the Security Considerations
section from that document (with new section numbers). Our comments
are indented and prefaced with 'NOTE:'.

6.2.1. Security Considerations

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.

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.

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.

6.2.1.1. No Authentication

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).

Rescorla & Korver Best Current Practice [Page 41]

4.5.2.2. Remote 36]

RFC 3552 Security Considerations Guidelines July 2003

6.2.1.2. Simple Text Password

The use of this authentication type means that VRRP protocol
exchanges are authenticated by a simple clear text password.

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.

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 TLS . . . . . . . . . . . . . . . 20
4.5.3. Remote Login . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6. Denial therefore should not be the
same as any security significant password.

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.

6.2.1.3. IP Authentication Header

The use of Service Attacks this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP
Authentication Header [AH] using [HMAC]. This provides strong
protection against configuration errors, replay attacks, and Countermeasures . . . . . . . . . 21
4.6.1. Blind Denial packet
corruption/modification.

This type of Service . . . . . . . . . . . . . . . . . . . 21
4.6.2. Distributed Denial authentication is RECOMMENDED when there is limited
control over the administration of Service . . . . . . . . . . . . . . . . 22
4.6.3. Avoiding Denial nodes on a LAN. While this type
of Service . . . . . . . . . . . . . . . . . 22
4.6.3.1. Make your 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.

Rescorla & Korver Best Current Practice [Page 37]

RFC 3552 Security Considerations Guidelines July 2003

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.

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.

[The rest of this section is NEW material]
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.

However, it is not necessary for an attacker to be the VRRP master to
do more work than you do . . . . . . . . 22
4.6.3.2. Make your this. An attacker prove they can receive data from you
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6.4. Example: TCP SYN Floods . . . . . . . . . . . . . . . . . . . 23
4.6.5. Example: Photuris . . . . . . . . . . . . . . . . . . . . . . 23
4.7. Object vs. Channel Security . . . . . . . . . . . . . . . . . . 23
4.8. Firewalls 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.

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 Network Topology . . . . . . . . . . . . . . . . 24
5. Writing therefore both will attempt to be master. This creates
substantial network instability.

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.

7. Acknowledgments

This document is heavily based on a note written by Ran Atkinson in
1997. That note was written after the IAB Security Considerations Sections . . . . . . . . . . . . 24
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.1. 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 this document is specific
comments received from Steve Bellovin. Early review of this 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.

Rescorla & Korver Best Current Practice [Page 38]

RFC 3552 Security Considerations . . . . . . . . . . . . . . . . . . . 27
6.1.1.1. Mail Guidelines July 2003

8. Normative References

[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.

[DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.

[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946,
September, 2000.

[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.

[GSS] Linn, J., "Generic Security Services Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "HyperText
Transfer Protocol", RFC 2616, June 1999.

[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.

[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.

KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", STD 61, RFC 2289, February 1998.

[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.

[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 "Public Key Infrastructure Certificate and Spoofing . . . . . . . . . . . . . . . . 27
6.1.1.2. Blind Copies . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.1.3. VRFY, EXPN,
Certificate Restoration List (CRL) Profile", RFC 3280,
April 2002.

[RFC-2223] Postel J. and Security . . . . . . . . . . . . . . . . . 29
6.1.1.4. Information Disclosure in Announcements . . . . . . . . . . 30
6.1.1.5. Information Disclosure in Trace Fields . . . . . . . . . . 30
6.1.1.6. Information Disclosure in Message Forwarding . . . . . . . 30
6.1.1.7. Scope of Operation of J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.

[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP Servers . . . . . . . . . . . . 30
6.1.1.8. Inappropriate Usage [NEW] . . . . . . . . . . . . . . . . . 31
6.1.1.8.1. Closed Relaying [NEW] . . . . . . . . . . . . . . . . . . 31
6.1.1.8.2. Endpoints [NEW] . . . . . . . . . . . . . . . . . . . . . 32
6.1.2. Communications security issues . . . . . . . . . . . . . . . 32
6.1.2.1. MTAs",
BCP 30, RFC 2505, February 1999.

Rescorla & Korver Best Current Practice [Page 39]

RFC 3552 Security Considerations Guidelines July 2003

[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.

[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.

[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.

[SSH] Ylonen, T., "SSH - Secure Login Connections Over the
Internet", 6th USENIX Security Symposium, p. 37-42, July
1996.

[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.

[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over IPSEC [NEW] . . . . . . . . . . . . . . . . . . . 32
6.1.2.2. SMTP/TLS [NEW] . . . . . . . . . . . . . . . . . . . . . . 33
6.1.2.3. S/MIME
Transport Layer Security", RFC 3207, February 2002.

[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText
Transfer Protocol", RFC 2660, August 1999.

[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message
Specification", RFC 2633, June 1999.

[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.

[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.

[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D. and J.
Mikkelsen, "Transport Layer Security (TLS) Extensions",
RFC 3546, May 2003.

[TCPSYN] "TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory
CA-1996-21, 19 September 1996, CERT.
http://www.cert.org/advisories/CA-1996-21.html

[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.

[URL] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.

Rescorla & Korver Best Current Practice [Page 40]

RFC 3552 Security Considerations Guidelines July 2003

[VRRP] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel,
D., Hunt, P., Higginson, P., Shand, M. and PGP/MIME [NEW] . . . . . . . . . . . . . . . . . 33
6.1.3. Denial A. Lindemn,
"Virtual Router Redundancy Protocol", RFC 2338, April
1998.

9. Informative References

[DDOS] "Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28
December 1999, CERT http://www.cert.org/advisories/CA-
1999-17.html

[EKE] Bellovin, S., Merritt, M., "Encrypted Key Exchange:
Password-based protocols secure against dictionary
attacks", Proceedings of Service . . . . . . . . . . . . . . . . . . . . . . 34
6.2. VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1. the IEEE Symposium on Research in
Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.2.1.1. No Authentication . . . . . . . . . . . . . . . . . . . . . 35
6.2.1.2. Simple Text and Privacy, May 1992.

[IDENT] St. Johns, M. and M. Rose, "Identification Protocol", RFC
1414, February 1993.

[INTAUTH] Haller, N. and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.

[IPSPPROB] Bellovin, S. M., "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix UNIX Security
Symposium, July 1996.

[KLEIN] Klein, D.V., "Foiling the Cracker: A Survey of and
Improvements to Password Security", 1990.

[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.

[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.

[SEQNUM] Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP
Software", AT&T Bell Laboratories, CSTR 117, 1985.

[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D., "Simple
Object Access Protocol (SOAP) 1.1", May 2000.

[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", Computer Communication Review, ACM SIGCOMM,
vol. 26, no. 5, pp. 5-26, October 1996.

[SRP] Wu T., "The Secure Remote Password . . . . . . . . . . . . . . . . . . . 35
6.2.1.3. IP Authentication Header . . . . . . . . . . . . . . . . . 35
6.2.1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36
6.2.1.3. Normative References . . . . . . . . . . . . . . . . . . . 37
6.2.1.3. Informative References . . . . . . . . . . . . . . . . . . 39 Protocol", ISOC NDSS
Symposium, 1998.

Rescorla & Korver Best Current Practice [Page 41]

RFC 3552 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Rescorla, Guidelines July 2003

[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
Work in Progress.

[WEP] Borisov, N., Goldberg, I., Wagner, D., "Intercepting
Mobile Communications: The Insecurity of 802.11",
http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf

10. Security Considerations

This entire document is about security considerations.

Rescorla & Korver Best Current Practice [Page 42]Internet-Draft

RFC 3552 Security Considerations Guidelines July 2003

Appendix A.

IAB Members at the time of this writing

Harald Alvestrand
Ran Atkinson
Rob Austein
Fred Baker
Leslie Daigle
Steve Deering
Sally Floyd
Ted Hardie
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Mike St. Johns

Authors' Addresses

Eric Rescorla
RTFM, Inc.
2439 Alvin Drive
Mountain View, CA 94043

Phone: (650)-320-8549
EMail: ekr@rtfm.com

Brian Korver
Xythos Software, Inc.
77 Maiden Lane, 6th Floor
San Francisco, CA, 94108

Phone: (415)-248-3800
EMail: briank@xythos.com

Internet Architecture Board
IAB
EMail: iab@iab.org

Rescorla & Korver Best Current Practice [Page 43]

RFC 3552 Security Considerations Guidelines July 2003

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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

Rescorla & Korver Best Current Practice [Page 44]

----