doc: Add RFC documents

1 files changed, 2467 insertions, 0 deletions

diff --git a/doc/rfc/rfc3552.txt b/doc/rfc/rfc3552.txt
new file mode 100644
index 0000000..37a94da
--- /dev/null
+++ b/doc/rfc/rfc3552.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group                                        E. Rescorla
+Request for Comments: 3552                                    RTFM, Inc.
+BCP: 72                                                        B. Korver
+Category: Best Current Practice                          Xythos Software
+                                             Internet Architecture Board
+                                                                     IAB
+                                                               July 2003
+
+
+       Guidelines for Writing RFC Text on Security Considerations
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   All RFCs are required to have a Security Considerations section.
+   Historically, such sections have been relatively weak.  This document
+   provides guidelines to RFC authors on how to write a good Security
+   Considerations section.
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
+      1.1. Requirements. . . . . . . . . . . . . . . . . . . . .   3
+   2. The Goals of Security. . . . . . . . . . . . . . . . . . .   3
+      2.1. Communication Security. . . . . . . . . . . . . . . .   3
+           2.1.1. Confidentiality. . . . . . . . . . . . . . . .   4
+           2.1.2. Data Integrity . . . . . . . . . . . . . . . .   4
+           2.1.3. Peer Entity authentication . . . . . . . . . .   4
+      2.2. Non-Repudiation . . . . . . . . . . . . . . . . . . .   5
+      2.3. Systems Security. . . . . . . . . . . . . . . . . . .   5
+           2.3.1. Unauthorized Usage . . . . . . . . . . . . . .   6
+           2.3.2. Inappropriate Usage. . . . . . . . . . . . . .   6
+           2.3.3. Denial of Service. . . . . . . . . . . . . . .   6
+   3. The Internet Threat 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 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. . . . . . . . . . .  18
+           4.4.1. Access Control Lists . . . . . . . . . . . . .  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 Service Attacks and Countermeasures . . . .  22
+           4.6.1. Blind Denial of Service. . . . . . . . . . . .  23
+           4.6.2. Distributed Denial of Service. . . . . . . . .  23
+           4.6.3. Avoiding Denial of Service . . . . . . . . . .  24
+           4.6.4. Example: TCP SYN Floods. . . . . . . . . . . .  24
+           4.6.5. Example: Photuris. . . . . . . . . . . . . . .  25
+      4.7. Object vs. Channel Security . . . . . . . . . . . . .  25
+      4.8. Firewalls and 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 issues . . . . . . . .  34
+           6.1.3. Denial of 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 2]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  43
+   Full Copyright Statement. . . . . . . . . . . . . . . . . . .  44
+
+1. Introduction
+
+   All RFCs are required by RFC 2223 to contain a Security
+   Considerations section.  The purpose of this is both to encourage
+   document authors to consider security in their designs and to inform
+   the reader of relevant security issues.  This memo is intended to
+   provide guidance to RFC authors in service of both ends.
+
+   This document is structured in three parts.  The first is a
+   combination security tutorial and definition of common terms; the
+   second is a series of guidelines for writing Security Considerations;
+   the third is a series of examples.
+
+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 BCP 14, RFC 2119
+   [KEYWORDS].
+
+2. The Goals of Security
+
+   Most people speak of security as if it were a single monolithic
+   property of a protocol or system, however, upon reflection, one
+   realizes that it is clearly not true.  Rather, security is a series
+   of related but somewhat independent properties.  Not all of these
+   properties are required for every application.
+
+   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 goals of communication security
+   differently.  The partitioning we've found most useful is to divide
+   them into three major categories: CONFIDENTIALITY, DATA INTEGRITY and
+   PEER ENTITY AUTHENTICATION.
+
+
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                  [Page 3]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+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, it poses a risk to your
+   confidentiality.
+
+   Obviously, if you have secrets, then you are probably concerned about
+   others discovering them.  Thus, at the very least, you want to
+   maintain confidentiality.  When you see spies in the movies go into
+   the bathroom and turn on all the water to foil bugging, the property
+   they're looking for is confidentiality.
+
+2.1.2. Data Integrity
+
+   The second primary goal is DATA INTEGRITY.  The basic idea here is
+   that we want to make sure that the data we receive is the same data
+   that the sender has sent.  In paper-based systems, some data
+   integrity comes automatically.  When you receive a letter written in
+   pen you can be fairly certain that no words have been removed by an
+   attacker because pen marks are difficult to remove from paper.
+   However, an attacker could have easily added some marks to the paper
+   and completely changed the meaning of the message.  Similarly, it's
+   easy to shorten the page to truncate the message.
+
+   On the other hand, in the electronic world, since all bits look
+   alike, it's trivial to tamper with messages in transit.  You simply
+   remove the message from the wire, copy out the parts you like, add
+   whatever data you want, and generate a new message of your choosing,
+   and the recipient is no wiser.  This is the moral equivalent of the
+   attacker taking a letter you wrote, buying some new paper and
+   recopying the message, changing it as he does it.  It's just a lot
+   easier to do electronically since all bits look alike.
+
+2.1.3. Peer Entity authentication
+
+   The third property we're concerned with is PEER ENTITY
+   AUTHENTICATION.  What we mean by this is that we know that one of the
+   endpoints in the communication is the one we intended.  Without peer
+   entity authentication, it's very difficult to provide either
+   confidentiality or data integrity.  For instance, if we receive a
+   message from Alice, the property of data integrity doesn't do us much
+   good unless we know that it was in fact sent by Alice and not the
+   attacker.  Similarly, if we want to send a confidential message to
+   Bob, it's not of much value to us if we're actually sending a
+   confidential message to the attacker.
+
+
+
+
+Rescorla & Korver        Best Current Practice                  [Page 4]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   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
+   authentication to establish the identity of the sender of a certain
+   message.  In such contexts, this property is called DATA ORIGIN
+   AUTHENTICATION.
+
+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 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.
+   Consider the situation in which two parties have signed a contract
+   which one party wishes to unilaterally abrogate.  He might simply
+   claim that he had never signed it in the first place.  Non-
+   repudiation prevents him from doing so, thus protecting the
+   counterparty.
+
+   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.
+
+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.
+   Furthermore, they should be available for those purposes.  Attackers
+   should not 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 be completely accessible to the
+   public.  Rather, they are intended to be used only by certain
+   authorized individuals.  Although many Internet services are
+   available to all Internet users, even those servers generally offer a
+   larger subset of services to specific users.  For instance, Web
+   Servers often will serve data to any user, but restrict the ability
+   to modify pages to specific users.  Such modifications by the general
+   public would be UNAUTHORIZED USAGE.
+
+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
+   authorized users, some to specific users, and some activities are
+   generally forbidden to all but administrators.  Moreover, even
+   activities which are in general permitted might be forbidden in some
+   cases.  For instance, users may be permitted to send email but
+   forbidden from sending files above a certain size, or files which
+   contain viruses.  These are examples of INAPPROPRIATE USAGE.
+
+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.
+
+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
+
+
+
+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 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.
+
+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' 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
+   section 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
+   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 network segment which that machine is on.
+
+   Similarly, an attacker who has control of a host in the
+   communications path between two victim machines is able to mount a
+   passive attack on their communications.  It is also possible to
+   compromise the routing infrastructure to specifically arrange that
+   traffic passes through a compromised machine.  This might involve an
+   active attack on the routing infrastructure to facilitate a passive
+   attack on a victim machine.
+
+   Wireless communications channels deserve special consideration,
+   especially with the recent and growing popularity of wireless-based
+   LANs, such as those using 802.11.  Since the data is simply broadcast
+   on well known radio frequencies, an attacker simply needs to be able
+   to receive those transmissions.  Such channels are especially
+   vulnerable to passive attacks.  Although many such channels include
+   cryptographic protection, it is often of such poor quality as to be
+   nearly useless [WEP].
+
+   In general, the goal of a passive attack is to obtain information
+   which the sender and receiver would prefer to remain private.  This
+   private information may include credentials useful in the electronic
+   world and/or passwords or credentials useful in the outside world,
+   such as confidential business information.
+
+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
+   availability of SSL, many credit card transactions still traverse the
+   Internet in the clear.  An attacker could sniff such a message and
+   recover the credit card number, which can then be used to make
+   fraudulent transactions.  Moreover, confidential business information
+   is routinely transmitted over the network in the clear in email.
+
+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
+   traffic can therefore capture the password and REPLAY it.  In other
+   words, the attacker can initiate a connection to the server and pose
+   as the client and login using the captured password.
+
+
+
+Rescorla & Korver        Best Current Practice                  [Page 8]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   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
+   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
+   protection against an attacker who is inside the 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 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.
+
+   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 practice to disguise one's address in order to
+   conceal one's identity if an attack is discovered.
+
+   Each protocol is susceptible to specific active attacks, but
+   experience shows that a number of common patterns of attack can be
+   adapted to any given protocol.  The next sections describe a number
+   of these patterns and give specific examples of them as applied to
+   known protocols.
+
+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
+   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
+
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 10]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   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' 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.
+
+   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.
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 11]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+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
+   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
+   transaction in order to prevent man-in-the-middle attacks.  In such a
+   situation the the peers can establish an association in which only
+   one peer is authenticated.  In such a system, an attacker can
+   initiate an association posing as the unauthenticated peer but cannot
+   transmit or access data being sent on a legitimate connection.  This
+   is an acceptable situation in contexts such as Web e-commerce where
+   only the server needs to be authenticated (or the client is
+   independently authenticated via some non-cryptographic mechanism such
+   as a credit card number).
+
+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.
+
+
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 12]
+
+RFC 3552           Security Considerations Guidelines          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 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
+   datagrams intended for other hosts.  Thus, if an attack depends on
+   being able to receive data, off-path hosts must first subvert the
+   topology in order to place themselves on-path.  This is by no means
+   impossible but is not necessarily trivial.
+
+   Applications protocol designers MUST NOT assume that all attackers
+   will be off-path.  Where possible, protocols SHOULD be designed to
+   resist attacks from attackers who have complete control of the
+   network.  However, designers are expected to give more weight to
+   attacks which can be mounted by off-path attackers as well as on-path
+   ones.
+
+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
+   decremented by each forwarder, a protocol can demand that TTL be set
+   to 255 and that all receivers verify the TTL.  A receiver then has
+   some reason to believe that conforming packets are from the same
+   link.  Note that this technique must be used with care in the
+   presence of tunneling systems, since such systems may pass packets
+   without decrementing TTL.
+
+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 obvious but insecure solution even though better solutions
+   are available.  This section describes a number of issues seen in
+   many protocols and the common pieces of security technology that may
+   be useful in addressing them.
+
+
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 13]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+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 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
+   passive attack): As previously mentioned, often the one-time password
+   or response is computed from a shared secret.  If the attacker knows
+   the function being used, he can simply try all possible shared
+   secrets until he finds one that produces the right output.  This is
+   made easier if the shared secret is a password, in which case he can
+   mount a DICTIONARY ATTACK -- meaning that he tries a list of common
+   words (or strings) rather than just random strings.
+
+   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.
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 14]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+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-
+   generated passwords.  If the keys are sufficiently large then
+   keysearch attacks become impractical.  This approach works best when
+   the keys are configured into the end nodes rather than memorized and
+   typed in by users, since users have trouble remembering sufficiently
+   long keys.
+
+   Like password-based systems, shared key systems suffer from
+   management problems.  Each pair of communicating parties must have
+   their own agreed-upon key, which leads to there being a lot of keys.
+
+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
+   DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with
+   each party in the system.  It first contacts the KDC which gives it a
+   TICKET containing a randomly generated symmetric key encrypted under
+   both peer's keys.  Since only the proper peers can decrypt the
+   symmetric key the ticket can be used to establish a trusted
+   association.  By far the most popular KDC system is Kerberos
+   [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
+   [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
+   connection after authentication has been performed.  A number of
+   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 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
+   binding 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
+   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 the problem of choosing authentication and key
+   establishment mechanisms, one needs to integrate it into a protocol.
+   One response to this problem (embodied in IPsec and TLS) is to create
+   a lower-level security protocol and then insist that new protocols be
+   run over that protocol.  Another approach that has recently become
+   popular is to design generic application layer security frameworks.
+   The idea is that you design a protocol that allows you to negotiate
+   various security mechanisms in a pluggable fashion.  Application
+   protocol designers then arrange to carry the security protocol PDUs
+   in their application protocol.  Examples of such frameworks include
+   GSS-API [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
+   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 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
+   security features in the framework interact with the application
+   layer protocol.  For instance, SASL can be used merely as an
+   authentication framework -- in which case the SASL exchange occurs
+   but the rest of the connection is unprotected, but can also negotiate
+   traffic protection, such as via GSS, as a mechanism.  Knowing under
+   what circumstances traffic protection is optional and which it is
+   required requires thinking about the threat model.
+
+   In general, authentication frameworks are most useful in situations
+   where new protocols are being added to systems with pre-existing
+   legacy authentication systems.  A framework allows new installations
+   to provide better authentication while not forcing existing sites
+   completely redo their legacy authentication systems.  When the
+   security requirements of a system can be clearly identified and only
+   a few forms of authentication are used, choosing a single security
+   mechanism leads to greater simplicity and predictability.  In
+   situations where a framework is to be used, designers SHOULD
+   carefully examine the framework's options and specify only the
+   mechanisms that are appropriate for their particular threat model.
+   If a framework is necessary, designers SHOULD choose one of the
+   established ones instead of designing their own.
+
+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
+   signature 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
+   disputed message.  In order to defend against this attack the relying
+   party needs to demonstrate that the signing party's key had not been
+   compromised at the time of the signature.  This requires substantial
+   infrastructure, including archival storage of certificate revocation
+   information and timestamp servers to establish the time that the
+   message was signed.
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 17]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   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.
+
+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
+   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 imply authorization.  Rather, before
+   granting permission to perform an action, the authorization mechanism
+   must be 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 resource.
+   Since assigning individual authorization permissions to each resource
+   is tedious, resources are often hierarchically arranged so that the
+   parent resource's ACL is inherited by child resources.  This allows
+   administrators to set top level policies and override them when
+   necessary.
+
+4.4.2. Certificate Based Systems
+
+   While the distinction between authentication and authorization is
+   intuitive when using simple authentication mechanisms such as
+   username and password (i.e., everyone understands the difference
+   between the administrator account and a user account), with more
+   complex authentication mechanisms the distinction is sometimes lost.
+
+   With certificates, for instance, presenting a valid signature does
+   not imply authorization.  The signature must be backed by a
+   certificate chain that contains a trusted root, and that root must be
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 18]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   trusted in the given context.  For instance, users who possess
+   certificates issued by the Acme MIS CA may have different web access
+   privileges than users who possess certificates issued by the Acme
+   Accounting CA, even though both of these CAs are "trusted" by the
+   Acme web server.
+
+   Mechanisms for enforcing these more complicated properties have not
+   yet been completely explored.  One approach is simply to attach
+   policies to ACLs describing what sorts of certificates are trusted.
+   Another approach is to carry that information with the certificate,
+   either as a certificate extension/attribute [PKIX, SPKI] or as a
+   separate "Attribute Certificate".
+
+4.5. Providing Traffic Security
+
+   Securely designed protocols should provide some mechanism for
+   securing (meaning integrity protecting, authenticating, and possibly
+   encrypting) all sensitive traffic.  One approach is to secure the
+   protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP].  Although this
+   provides security which is most fitted to the protocol, it also
+   requires considerable effort to get right.
+
+   Many protocols can be adequately secured using one of the available
+   channel security systems.  We'll discuss the two most common, IPsec
+   [AH, ESP] and [TLS].
+
+4.5.1. IPsec
+
+   The IPsec protocols (specifically, AH and ESP) can provide
+   transmission security for all traffic between two hosts.  The IPsec
+   protocols support varying granularities of user identification,
+   including for example "IP Subnet", "IP Address", "Fully Qualified
+   Domain Name", and individual user ("Mailbox name").  These varying
+   levels of identification are employed as inputs to access control
+   facilities that are an intrinsic part of IPsec.  However, a given
+   IPsec implementation might not support all identity types.  In
+   particular, security gateways may not provide user-to-user
+   authentication or have mechanisms to provide that authentication
+   information to applications.
+
+   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.
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 19]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   The primary obstacle to using IPsec to secure other protocols is
+   deployment.  The major use of IPsec at present is for VPN
+   applications, especially for remote network access.  Without
+   extremely tight coordination between security administrators and
+   application developers, VPN usage is not well suited to providing
+   security services for individual applications since it is difficult
+   for such applications to determine what security services have in
+   fact been provided.
+
+   IPsec deployment in host-to-host environments has been slow.  Unlike
+   application security systems such as TLS, adding IPsec to a non-IPsec
+   system generally involves changing the operating system, either by
+   modifying with the kernel or installing new drivers.  This is a
+   substantially greater undertaking than simply installing a new
+   application.  However, recent versions of a number of commodity
+   operating systems include IPsec stacks, so deployment is becoming
+   easier.
+
+   In environments where IPsec is sure to be available, it represents a
+   viable option for protecting application communications traffic.  If
+   the traffic to be protected is UDP, IPsec and application-specific
+   object security are the only options.  However, designers MUST NOT
+   assume that IPsec will be available.  A security policy for a generic
+   application layer protocol SHOULD NOT simply state that IPsec must be
+   used, unless there is some reason to believe that IPsec will be
+   available in the intended deployment environment.  In environments
+   where IPsec may not be available and the traffic is solely TCP, TLS
+   is the method of choice, since the application developer can easily
+   ensure its presence by including a TLS implementation in his package.
+
+   In the special-case of IPv6, both AH and ESP are mandatory to
+   implement.  Hence, it is reasonable to assume that AH/ESP are already
+   available for IPv6-only protocols or IPv6-only deployments.  However,
+   automatic key management (IKE) is not required to implement so
+   protocol designers SHOULD not assume it will be present.  [USEIPSEC]
+   provides quite a bit of guidance on when IPsec is a good choice.
+
+4.5.2. SSL/TLS
+
+   Currently, the most common approach is to use SSL or its successor
+   TLS.  They provide channel security for a TCP connection at the
+   application level.  That is, they run over TCP.  SSL implementations
+   typically provide a Berkeley Sockets-like interface for easy
+   programming.  The primary issue when designing a protocol solution
+   around TLS is to differentiate between connections protected using
+   TLS and those which are not.
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 20]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   The 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 TLS depends upon a reliable protocol such as TCP or SCTP.
+   This produces two notable difficulties.  First, it cannot be used to
+   secure datagram protocols that use UDP.  Second, TLS is susceptible
+   to IP layer attacks that IPsec is not.  Typically, these attacks take
+   some form of denial of service or connection assassination.  For
+   instance, an attacker might forge a TCP RST to shut down SSL
+   connections.  TLS has mechanisms to detect truncation attacks but
+   these merely allow the victim to know he is being attacked and do not
+   provide connection survivability in the face of such attacks.  By
+   contrast, if IPsec were being used, such a forged RST could be
+   rejected without affecting the TCP connection.  If forged RSTs or
+   other such attacks on the TCP connection are a concern, then AH/ESP
+   or the TCP MD5 option [TCPMD5] are the preferred choices.
+
+4.5.2.1. Virtual Hosts
+
+   If the "separate ports" approach to TLS is used, then TLS will be
+   negotiated before any application-layer traffic is sent.  This can
+   cause a problem with protocols that use virtual hosts, such as
+   [HTTP], since the server does not know which certificate to offer the
+   client during the TLS handshake.  The TLS hostname extension [TLSEXT]
+   can be used to solve this problem, although it is too new to have
+   seen wide deployment.
+
+4.5.2.2. Remote Authentication and TLS
+
+   One difficulty with using TLS is that the server is authenticated via
+   a certificate.  This can be inconvenient in environments where
+   previously the only form of authentication was a password shared
+   between client and server.  It's tempting to use TLS without an
+   authenticated server (i.e., with anonymous DH or a self-signed RSA
+   certificate) and then authenticate via some challenge-response
+   mechanism such as SASL with CRAM-MD5.
+
+   Unfortunately, this composition of SASL and TLS is less strong than
+   one would expect.  It's easy for an active attacker to hijack this
+   connection.  The client man-in-the-middles the SSL connection
+   (remember we're not authenticating the server, which is what
+   ordinarily prevents this attack) and then simply proxies the SASL
+   handshake.  From then on, it's as if the connection were in the
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 21]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   clear, at least as far as that attacker is concerned.  In order to
+   prevent this attack, the client needs to verify the server's
+   certificate.
+
+   However, if the server is authenticated, challenge-response becomes
+   less desirable.  If you already have a hardened channel then simple
+   passwords are fine.  In fact, they're arguably superior to
+   challenge-response since they do not require that the password be
+   stored in the clear on the server.  Thus, compromise of the key file
+   with challenge-response systems is more serious than if simple
+   passwords were used.
+
+   Note that if the client has a certificate than SSL-based client
+   authentication can be used.  To make this easier, SASL provides the
+   EXTERNAL mechanism, whereby the SASL client can tell the server
+   "examine the outer channel for my identity".  Obviously, this is not
+   subject to the layering attacks described above.
+
+4.5.3. Remote Login
+
+   In some special cases it may be worth providing channel-level
+   security directly in the application rather than using IPSEC or
+   SSL/TLS.  One such case is remote terminal security.  Characters are
+   typically delivered from client to server one character at a time.
+   Since SSL/TLS and AH/ESP authenticate and encrypt every packet, this
+   can mean a data expansion of 20-fold.  The telnet encryption option
+   [ENCOPT] prevents this expansion by foregoing message integrity.
+
+   When using remote terminal service, it's often desirable to securely
+   perform other sorts of 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 SSH channel.  Note that SSH Port
+   Forwarding can be security issue if it is used improperly to
+   circumvent firewall and improperly expose insecure internal
+   applications to the outside world.
+
+4.6. Denial of Service Attacks and Countermeasures
+
+   Denial of service attacks are all too frequently viewed as an fact of
+   life.  One problem is that an attacker can often choose from one of
+   many denial of service attacks to inflict upon a victim, and because
+   most of these attacks cannot be thwarted, common wisdom frequently
+   assumes that there is no point protecting against one kind of denial
+   of service attack when there are many other denial of service attacks
+   that are possible but that cannot be prevented.
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 22]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+   However, not all denial of service attacks are equal and more
+   importantly, it is possible to design protocols so that denial of
+   service attacks are made more difficult, if not impractical.  Recent
+   SYN flood attacks [TCPSYN] demonstrate both of these properties: SYN
+   flood attacks are so easy, anonymous, and effective that they are
+   more attractive to attackers than other attacks; and because the
+   design of TCP enables this attack.
+
+   Because complete DoS protection is so difficult, security against DoS
+   must be dealt with pragmatically.  In particular, some attacks which
+   would be desirable to defend against cannot be defended against
+   economically.  The goal should be to manage risk by defending against
+   attacks with sufficiently high ratios of severity to cost of defense.
+   Both severity of attack and cost of defense change as technology
+   changes and therefore so does the set of attacks which should be
+   defended against.
+
+   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
+
+   BLIND denial of service attacks are particularly pernicious.  With a
+   blind attack the attacker has a significant advantage.  If the
+   attacker must be able to receive traffic from the victim, then he
+   must either subvert the routing fabric or use his own IP address.
+   Either provides an opportunity for the victim to track the attacker
+   and/or filter out his traffic.  With a blind attack the attacker can
+   use forged IP addresses, making it extremely difficult for the victim
+   to filter out his packets.  The TCP SYN flood attack is an example of
+   a blind attack.  Designers should make every attempt possible to
+   prevent blind denial of service attacks.
+
+4.6.2. Distributed Denial of Service
+
+   Even more dangerous are DISTRIBUTED denial of service attacks (DDoS)
+   [DDOS].  In a DDoS the attacker arranges for a number of machines to
+   attack the target machine simultaneously.  Usually this is
+   accomplished by infecting a large number of machines with a program
+   that allows remote initiation of attacks.  The machines actually
+   performing the attack are called ZOMBIEs and are likely owned by
+   unsuspecting third parties in an entirely different location from the
+   true attacker.  DDoS attacks can be very hard to counter because the
+   zombies often appear to be making legitimate protocol requests and
+
+
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 23]
+
+RFC 3552           Security 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 track)
+   or to forge an address which will be routed back along a path that
+   traverses the host from which the attack is being launched.
+
+   Hosts on small subnets are thus useless to the attacker (at least in
+   the context of a spoofing attack) because the attack can be traced
+   back to a subnet (which should be sufficient for locating the
+   attacker) so that anti-attack measures can be put into place (for
+   instance, a boundary router can be configured to drop all traffic
+   from that subnet).  A common technique is to require that the
+   attacker reply using information that was gained earlier in the
+   message exchange.
+
+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
+   attacker can perform this action without ever having received data
+   from the victim, the attack can be performed anonymously (and
+   therefore using a large number of forged source addresses).
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 24]
+
+RFC 3552           Security Considerations Guidelines          July 2003
+
+
+4.6.5. Example: Photuris
+
+   [PHOTURIS] specifies an anti-clogging mechanism that prevents attacks
+   on Photuris that resemble the SYN flood attack.  Photuris employs a
+   time-variant secret to generate a "cookie" which is returned to the
+   attacker.  This cookie must be returned in subsequent messages for
+   the exchange to progress.  The interesting feature is that this
+   cookie can be regenerated by the victim later in the exchange, and
+   thus no state need be retained by the victim until after the attacker
+   has proven that he can receive packets from the victim.
+
+4.7. Object vs. Channel Security
+
+   It's useful to make the conceptual distinction between object
+   security and channel security.  Object security refers to security
+   measures which apply to entire data objects.  Channel security
+   measures provide a secure channel over which objects may be carried
+   transparently but the channel has no special knowledge about object
+   boundaries.
+
+   Consider the case of an email message.  When it's carried over an
+   IPSEC or TLS secured connection, the message is protected during
+   transmission.  However, it is unprotected in the receiver's mailbox,
+   and in intermediate spool files along the way.  Moreover, since mail
+   servers generally run as a daemon, not a user, authentication of
+   messages generally merely means authentication of the daemon not the
+   user.  Finally, since mail transport is hop-by-hop, even if the user
+   authenticates to the first hop relay the authentication can't be
+   safely verified by the receiver.
+
+   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 Considerations Guidelines          July 2003
+
+
+   numerous inline images).  Thus, from the perspective of the total web
+   page, this looks rather more like channel security.  Object security
+   for a web page would consist of security for the transitive closure
+   of the page and all its embedded content as a single unit.
+
+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
+   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 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.
+
+   There is no inherent relationship between either "reverse" (from
+   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
+   transaction ("envelope") and the addresses in the headers.  Receiving
+   systems SHOULD NOT attempt to deduce such relationships and use them
+
+
+
+
+
+
+
+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 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 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 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 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 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 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 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 packet
+   corruption/modification.
+
+   This type of authentication is RECOMMENDED when there is limited
+   control over the administration of nodes on a LAN.  While this type
+   of authentication does protect the operation of VRRP, there are other
+   types of attacks that may be employed on shared media links (e.g.,
+   generation of bogus ARP replies) which are independent from VRRP and
+   are not protected.
+
+
+
+
+
+
+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 this.  An attacker can do similar kinds of damage to the network
+   by forging ARP packets or (on switched networks) fooling the switch
+   VRRP authentication offers no real protection against these attacks.
+
+   Unfortunately, authentication makes VRRP networks very brittle in the
+   face of misconfiguration.  Consider what happens if two nodes are
+   configured with different passwords.  Each will reject messages from
+   the other and therefore both will attempt to be master.  This creates
+   substantial network instability.
+
+   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 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 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
+              Certificate Restoration List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors",
+              RFC 2223, October 1997.
+
+   [RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP 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
+              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 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 the IEEE Symposium on Research in
+              Security 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 Protocol", ISOC NDSS
+              Symposium, 1998.
+
+
+
+Rescorla & Korver        Best Current Practice                 [Page 41]
+
+RFC 3552           Security Considerations 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]
+
+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
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   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]
+