[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 3552

                                                             E. Rescorla
                                                              RTFM, Inc.
                                                               B. Korver
                                                         Xythos Software
                                             Internet Architecture Board
INTERNET-DRAFT                                                       IAB
<draft-iab-sec-cons-02.txt>             January 2003 (Expires July 2003)

       Guidelines for Writing RFC Text on Security Considerations

Status of this Memo

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

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

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


Abstract

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

1. Introduction

   All RFCs are required by [RFC 2223] to contain a Security Considera-
   tions section. The purpose of this is both to encourage document
   authors to consider security in their designs and to inform the
   reader of relevant security issues. This memo is intended to provide
   guidance to RFC authors in service of both ends.

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



Rescorla, Korver                                                 [Page 1]

   is a series of examples.

1.1. Requirements

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

2. The Goals of Security

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

   We can loosely divide security goals into those related to protecting
   communications (COMMUNICATION SECURITY, also known as COMSEC) and
   those relating to protecting systems (ADMINISTRATIVE SECURITY or SYS-
   TEM SECURITY). Since communications are carried out by systems and
   access to systems is through communications channels, these goals
   obviously interlock, but they can also be independently provided.

2.1. Communication Security

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

2.1.1. Confidentiality

   When most people think of security, they think of CONFIDENTIALITY.
   Confidentiality means that your data is kept secret from unintended
   listeners. Usually, these listeners are simply eavesdroppers. When an
   adversary taps your phone, that poses a risk to your confidentiality.

   Obviously, if you have secrets, you're concerned that no-one else
   knows them and so at minimum you want confidentiality. When you see
   spies in the movies go into the bathroom and turn on all the water to
   foil bugging, the property they're looking for is confidentiality.

2.1.2. Data Integrity

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



Rescorla, Korver                                                 [Page 2]

Internet-Draft     Security Considerations Guidelines


   certain that no words have been removed by an attacker because pen
   marks are difficult to remove from paper. However, an attacker could
   have easily added some marks to the paper and completely changed the
   meaning of the message. Similarly, it's easy to shorten the page to
   truncate the message.

   On the other hand, in the electronic world, since all bits look
   alike, it's trivial to tamper with messages in transit. You simply
   remove the message from the wire, copy out the parts you like, add
   whatever data you want, and generate a new message of your choosing,
   and the recipient is no wiser. This is the moral equivalent of the
   attacker taking a letter you wrote, buying some new paper and recopy-
   ing the message, changing it as he does it. It's just a lot easier to
   do electronically since all bits look alike.

2.1.3. Peer Entity authentication

   The third property we're concerned with is PEER ENTITY AUTHENTICA-
   TION. What we mean by this is that we know that one of the endpoints
   in the communication is the one we intended. Without peer entity
   authentication, it's very difficult to provide either confidentiality
   or data integrity. For instance, if we receive a message from Alice,
   the property of data integrity doesn't do us much good unless we know
   that it was in fact sent by Alice and not the attacker. Similarly, if
   we want to send a confidential message to Bob, it's not of much value
   to us if we're actually sending a confidential message to the
   attacker.

   Note that peer entity authentication can be provided asymmetrically.
   When you call someone on the phone, you can be fairly certain that
   you have the right person -- or at least that you got a person who's
   actually at the phone number you called. On the other hand, if they
   don't have caller ID, then the receiver of a phone call has no idea
   who's calling them. Calling someone on the phone is an example of
   recipient authentication, since you know who the recipient of the
   call is, but they don't know anything about the sender.

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

2.2. Non-Repudiation

   A system that provides endpoint authentication allows one party to be
   certain of the identity of someone with whom he is communicating.
   When the system provides data integrity a receiver can be sure of
   both the sender's identity and that he is receiving the data that
   that sender meant to send. However, he cannot necessarily demonstrate



Rescorla, Korver                                                 [Page 3]

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

   There are many situations in which non-repudiation is desirable. Con-
   sider the situation in which two parties have signed a contract which
   one party wishes to unilaterally abrogate. He might simply claim that
   he had never signed it in the first place. Non-repudiation prevents
   him from doing so, thus protecting the counterparty.

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

2.3. Systems Security

   In general, systems security is concerned with protecting one's
   machines and data. The intent is that machines should be used only by
   authorized users and for the purposes that the owners intend. Fur-
   thermore, they should be available for those purposes. Attackers
   should not be able to deprive legitimate users of resources.

2.3.1. Unauthorized Usage

   Most systems are not intended to be completely accessible to the pub-
   lic. Rather, they are intended to be used only by certain authorized
   individuals. Although many Internet services are available to all
   Internet users, even those servers generally offer a larger subset of
   services to specific users. For instance, Web Servers often will
   serve data to any user, but restrict the ability to modify pages to
   specific users. Such modifications by the general public would be
   UNAUTHORIZED USAGE.

2.3.2. Inappropriate Usage

   Being an authorized user does not mean that you have free run of the
   system. As we said above, some activities are restricted to autho-
   rized users, some to specific users, and some activities are gener-
   ally forbidden to all but administrators. Moreover, even activities
   which are in general permitted might be forbidden in some cases. For
   instance, users may be permitted to send email but forbidden from
   sending files above a certain size, or files which contain viruses.
   These are examples of INAPPROPRIATE USAGE.







Rescorla, Korver                                                 [Page 4]

Internet-Draft     Security Considerations Guidelines


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

   By contrast, we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire. This includes being able to generate packets that
   appear to be from a trusted machine. Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.

   It's important to realize that the meaning of a PDU is different at
   different levels. At the IP level, a PDU means an IP packet. At the
   TCP level, it means a TCP segment. At the application layer, it means
   some kind of application PDU. For instance, at the level of email, it
   might either mean an RFC-822 message or a single SMTP command. At the
   HTTP level, it might mean a request or response.





Rescorla, Korver                                                 [Page 5]

3.1. Limited Threat Models

   As we've said, a resourceful and dedicated attacker can control the
   entire communications channel. However, a large number of attacks can
   be mounted by an attacker with fewer resources. A number of currently
   known attacks can be mounted by an attacker with limited control of
   the network. For instance, password sniffing attacks can be mounted
   by an attacker who can only read arbitrary packets. This is generally
   referred to as a PASSIVE ATTACK [INTAUTH]

   By contrast, Morris's sequence number guessing attack [SEQNUM] can be
   mounted by an attacker who can write but not read arbitrary packets.
   Any attack which requires the attacker to write to the network is
   known as an ACTIVE ATTACK.

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

3.2. Passive Attacks

   In a passive attack, the attacker reads packets off the network but
   does not write them. The simplest way to mount such an attack is to
   simply be on the same LAN as the victim. On most common LAN configu-
   rations, including Ethernet, 802.3, and FDDI, any machine on the wire
   can read all traffic destined for any other machine on the same LAN.
   Note that switching hubs make this sort of sniffing substantially
   more difficult, since traffic destined for a machine only goes to the
   network segment which that machine is on.

   Similarly, an attacker who has control of a host in the communica-
   tions path between two victim machines is able to mount a passive
   attack on their communications. It is also possible to compromise the
   routing infrastructure to specifically arrange that traffic passes
   through a compromised machine. This might involve an active attack on
   the routing infrastructure to facilitate a passive attack on a victim
   machine.

   Wireless communications channels deserve special consideration, espe-
   cially with the recent and growing popularity of wireless-based LANs,
   such as those using 802.11. Since the data is simply broadcast on
   well-known radio frequencies, an attacker simply needs to be able to
   receive those transmissions. Such channels are especially vulnerable
   to passive attacks. Although many such channels include cryptographic
   protection, it is often of such poor quality as to be nearly useless.
   [WEP]




Rescorla, Korver                                                 [Page 6]

Internet-Draft     Security Considerations Guidelines


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

3.2.1. Confidentiality Violations

   The classic example of passive attack is sniffing some inherently
   private data off of the wire. For instance, despite the wide avail-
   ability of SSL, many credit card transactions still traverse the
   Internet in the clear. An attacker could sniff such a message and
   recover the credit card number, which can then be used to make fraud-
   ulent transactions. Moreover, confidential business information is
   routinely transmitted over the network in the clear in email.

3.2.2. Password Sniffing

   Another example of a passive attack is PASSWORD SNIFFING. Password
   sniffing is directed towards obtaining unauthorized use of resources.
   Many protocols, including [TELNET], [POP], and [NNTP] use a shared
   password to authenticate the client to the server. Frequently, this
   password is transmitted from the client to the server in the clear
   over the communications channel. An attacker who can read this traf-
   fic can therefore capture the password and REPLAY it. That is to say
   that he can initiate a connection to the server and pose as the
   client and login using the captured password.

   Note that although the login phase of the attack is active, the
   actual password capture phase is passive. Moreover, unless the server
   checks the originating address of connections, the login phase does
   not require any special control of the network.

3.2.3. Offline Cryptographic Attacks

   Many cryptographic protocols are subject to OFFLINE ATTACKS. In such
   a protocol, the attacker recovers data which has been processed using
   the victim's secret key and then mounts a cryptanalytic attack on
   that key. Passwords make a particularly vulnerable target because
   they are typically low entropy. A number of popular password-based
   challenge response protocols are vulnerable to DICTIONARY ATTACK. The
   attacker captures a challenge-response pair and then proceeds to try
   entries from a list of common words (such as a dictionary file) until
   he finds a password that produces the right response.

   A similar such attack can be mounted on a local network when NIS is
   used. The Unix password is crypted using a one-way function, but
   tools exist to break such crypted passwords [KLEIN]. When NIS is



Rescorla, Korver                                                 [Page 7]

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

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

3.3. Active Attacks

   When an attack involves writing data to the network, we refer to this
   as an ACTIVE ATTACK. When IP is used without IPsec, there is no
   authentication for the sender address. As a consequence, it's
   straightforward for an attacker to create a packet with a source
   address of his choosing. We'll refer to this as a SPOOFING ATTACK.

   Under certain circumstances, such a packet may be screened out by the
   network. For instance, many packet filtering firewalls screen out all
   packets with source addresses on the INTERNAL network that arrive on
   the EXTERNAL interface. Note, however, that this provides no protec-
   tion against an attacker who is inside the firewall. In general,
   designers should assume that attackers can forge packets.

   However, the ability to forge packets does not go hand in hand with
   the ability to receive arbitrary packets. In fact, there are active
   attacks that involve being able to send forged packets but not
   receive the responses. We'll refer to these as BLIND ATTACKS.

   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. How-
   ever, 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 experi-
   ence shows that a number of common patterns of attack can be adapted
   to any given protocol. The next sections describe a number of these
   patterns and give specific examples of them as applied to known pro-
   tocols.

3.3.1. Replay Attacks

   In a REPLAY ATTACK, the attacker records a sequence of messages off
   of the wire and plays them back to the party which originally
   received them. Note that the attacker does not need to be able to
   understand the messages. He merely needs to capture and retransmit



Rescorla, Korver                                                 [Page 8]

Internet-Draft     Security Considerations Guidelines


   them.

   For example, consider the case where an S/MIME message is being used
   to request some service, such as a credit card purchase or a stock
   trade. An attacker might wish to have the service executed twice, if
   only to inconvenience the victim. He could capture the message and
   replay it, even though he can't read it, causing the transaction to
   be executed twice.

3.3.2. Message Insertion

   In a MESSAGE INSERTION attack, the attacker forges a message with
   some chosen set of properties and injects it into the network. Often
   this message will have a forged source address in order to disguise
   the identity of the attacker.

   For example, a denial-of-service attack can be mounted by inserting a
   series of spurious TCP SYN packets directed towards the target host.
   The target host responds with its own SYN and allocates kernel data
   structures for the new connection. The attacker never completes the
   3-way handshake, so the allocated connection endpoints just sit there
   taking up kernel memory. Typical TCP stack implementations only allow
   some limited number of connections in this "half-open" state and when
   this limit is reached, no more connections can be initiated, even
   from legitimate hosts. Note that this attack is a blind attack, since
   the attacker does not need to process the victim's SYNs.

3.3.3. Message Deletion

   In a MESSAGE DELETION attack, the attacker removes a message from the
   wire. Morris's sequence number guessing attack [SEQNUM] often
   requires a message deletion attack to be performed successfully. In
   this blind attack, the host whose address is being forged will
   receive a spurious TCP SYN packet from the host being attacked.
   Receipt of this SYN packet generates a RST, which would tear the
   illegitimate connection down. In order to prevent this host from
   sending a RST so that the attack can be carried out successfully,
   Morris describes flooding this host to create queue overflows such
   that the SYN packet is lost and thus never responded to.

3.3.4. Message Modification

   In a MESSAGE MODIFICATION attack, the attacker removes a message from
   the wire, modifies it, and reinjects it into the network. This sort
   of attack is particularly useful if the attacker wants to send some
   of the data in the message but also wants to change some of it.





Rescorla, Korver                                                 [Page 9]

   Consider the case where the attacker wants to attack an order for
   goods placed over the Internet. He doesn't have the victim's credit
   card number so he waits for the victim to place the order and then
   replaces the delivery address (and possibly the goods description)
   with his own. Note that this particular attack is known as a CUT-AND-
   PASTE attack since the attacker cuts the credit card number out of
   the original message and pastes it into the new message.

   Another interesting example of a cut-and-paste attack is provided by
   [IPSPPROB]. If IPsec ESP is used without any MAC then it is possible
   for the attacker to read traffic encrypted for a victim on the same
   machine. The attacker attaches an IP header corresponding to a port
   he controls onto the encrypted IP packet. When the packet is received
   by the host it will automatically be decrypted and forwarded to the
   attacker's port. Similar techniques can be used to mount a session
   hijacking attack. Both of these attacks can be avoided by always
   using message authentication when you use encryption. Note that this
   attack only works if (1) no MAC check is being used, since this
   attack generates damaged packets (2) a host-to-host SA is being used,
   since a user-to-user SA will result in an inconsistency between the
   port associated with the SA and the target port. If the receiving
   machine is single-user than this attack is infeasible.

3.3.5. Man-In-The-Middle

   A MAN-IN-THE-MIDDLE attack combines the above techniques in a special
   form: The attacker subverts the communication stream in order to pose
   as the sender to receiver and the receiver to the sender:

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

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


   This differs fundamentally from the above forms of attack because it
   attacks the identity of the communicating parties, rather than the
   data stream itself. Consequently, many techniques which provide
   integrity of the communications stream are insufficient to protect
   against man-in-the-middle attacks.

   Man-in-the-middle attacks are possible whenever a protocol lacks PEER
   ENTITY AUTHENTICATION. For instance, if an attacker can hijack the
   client TCP connection during the TCP handshake (perhaps by responding
   to the client's SYN before the server does), then the attacker can
   open another connection to the server and begin a man-in-the-middle
   attack. It is also trivial to mount man-in-the-middle attacks on



Rescorla, Korver                                                [Page 10]

Internet-Draft     Security Considerations Guidelines


   local networks via ARP spoofing--the attacker forges an ARP with the
   victim's IP address and his own MAC address. Tools to mount this sort
   of attack are readily available.

   Note that it is only necessary to authenticate one side of the trans-
   action in order to prevent man-in-the-middle attacks. In such a situ-
   ation the the peers can establish an association in which only one
   peer is authenticated. In such a system, an attacker can initiate an
   association posing as the unauthenticated peer but cannot transmit or
   access data being sent on a legitimate connection. This is an accept-
   able situation in contexts such as Web e-commerce where only the
   server needs to be authenticated (or the client is independently
   authenticated via some non-cryptographic mechanism such as a credit
   card number).

3.4. Topological Issues

   In practice, the assumption that it's equally easy for an attacker to
   read and generate all packets is false, since the Internet is not
   fully connected. This has two primary implications.

3.5. On-path versus off-path

   In order for a datagram to be transmitted from one host to another,
   it generally must traverse some set of intermediate links and gate-
   ways. Such gateways are naturally able to read, modify, or remove any
   datagram transmitted along that path. This makes it much easier to
   mount a wide variety of attacks if you are on-path.

   Off-path hosts can, of course, transmit arbitrary datagrams that
   appear to come from any hosts but cannot necessarily receive data-
   grams intended for other hosts. Thus, if an attack depends on being
   able to receive data, off-path hosts must first subvert the topology
   in order to place themselves on-pth. This is by no means impossible
   but is not necessarily trivial.

   Applications protocol designers MUST NOT assume that all attackers
   will be off-path. Where possible, protocols SHOULD be designed to
   resist attacks from attackers who have complete control of the net-
   work. However, designers are expected to give more weight to attacks
   which can be mounted by off-path attackers as well as on-path ones.

3.6. Link-local

   One specialized case of on-path is being on the same link. In some
   situations, it's desirable to distinguish between hosts who are on
   the local network and those who are not. The standard technique for
   this is verifying the IP TTL value. [IP] Since the TTL must be



Rescorla, Korver                                                [Page 11]

   decremented by each forwarder, a protocolcan demands that TTL be set
   to 255 and that all receivers verify the TTL. A receiver then has
   some reason to believe that conforming packets are from the same
   link. Note that this technique must be used with care in the presence
   of tunnelling systems, since such systems may pass packets without
   decrementing TTL.

4. Common Issues

   Although each system's security requirements are unique, certain com-
   mon requirements appear in a number of protocols. Often, when naive
   protocol designers are faced with these requirements, they choose an
   obvious but insecure solution even though better solutions are avail-
   able. This section describes a number of issues seen in many proto-
   cols and the common pieces of security technology that may be useful
   in addressing them.

4.1. User Authentication

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

4.1.1. Username/Password

   The most common access control mechanism is simple USERNAME/PASSWORD
   The user provides a username and a reusable password to the host
   which he wishes to use. This system is vulnerable to a simple passive
   attack where the attacker sniffs the password off the wire and then
   initiates a new session, presenting the password. This threat can be
   mitigated by hosting the protocol over an encrypted connection such
   as TLS or IPSEC. Unprotected (plaintext) username/password systems
   are not acceptable in IETF standards.

4.1.2. Challenge Response and One Time Passwords

   Systems which desire greater security than USERNAME/PASSWORD often
   employ either a ONE TIME PASSWORD [OTP] scheme or a CHALLENGE-
   RESPONSE. In a one time password scheme, the user is provided with a
   list of passwords, which must be used in sequence, one time each.
   (Often these passwords are generated from some secret key so the user
   can simply compute the next password in the sequence.) SecureID and
   DES Gold are variants of this scheme. In a challenge-response scheme,
   the host and the user share some secret (which often is represented
   as a password). In order to authenticate the user, the host presents
   the user with a (randomly generated) challenge. The user computes
   some function based on the challenge and the secret and provides that



Rescorla, Korver                                                [Page 12]

Internet-Draft     Security Considerations Guidelines


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

   Both types of scheme provide protection against replay attack, but
   often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of pas-
   sive attack): As previously mentioned, often the one-time password or
   response is computed from a shared secret. If the attacker knows the
   function being used, he can simply try all possible shared secrets
   until he finds one that produces the right output. This is made eas-
   ier if the shared secret is a password, in which case he can mount a
   DICTIONARY ATTACK--meaning that he tries a list of common words (or
   strings) rather than just random strings.

   These systems are also often vulnerable to an active attack. Unless
   communication security is provided for the entire session, the
   attacker can simply wait until authentication has been performed and
   hijack the connection.

4.1.3. 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.4. Some Uncommon Systems

   There are ways to do a better job than the schemes mentioned above,
   but they typically don't add much security unless communications
   security (at least message integrity) will be employed to secure the
   connection, because otherwise the attacker can merely hijack the con-
   nection after authentication has been performed. A number of proto-
   cols ( [EKE], [SPEKE], [SRP]) allow one to securely bootstrap a
   user's password into a shared key which can be used as input to a
   cryptographic protocol. One major obstacle to the deployment of these
   protocols has been that their Intellectual Property status is
   extremely unclear. Similarly, the user can authenticate using public
   key certificates. (e.g. S-HTTP client authentication). Typically
   these methods are used as part of a more complete security protocol.






Rescorla, Korver                                                [Page 13]

4.1.5. Host Authentication

   Host authentication presents a special problem. Quite commonly, the
   addresses of services are presented using a DNS hostname, for
   instance as a URL [URL]. When requesting such a service, one has to
   ensure that the entity that one is talking to not only has a
   certificate but that that certificate corresponds to the expected
   identity of the server. The important thing to have is a secure bind-
   ing between the certificate and the expected hostname.

   For instance, it is usually not acceptable for the certificate to
   contain an identity in the form of an IP address if the request was
   for a given hostname. This does not provide end-to-end security
   because the hostname-IP mapping is not secure unless secure name res-
   olution [DNSSEC] is being used. This is a particular problem when the
   hostname is presented at the application layer but the authentication
   is performed at some lower layer.

4.2. Generic Security Frameworks

   Providing security functionality in a protocol can be difficult. In
   addition to the problem of choosing authentication and key establish-
   ment mechanisms, one needs to integrate it into a protocol. One
   response to this problem (embodied in IPsec and TLS) is to create a
   lower-level security protocol and then insist that new protocols be
   run over that protocol.

   Another approach that has recently become popular is to design
   generic application layer security frameworks. The idea is that you
   design a protocol that allows you to negotiate various security mech-
   anisms in a pluggable fashion. Application protocol designers then
   arrange to carry the security protocol PDUs in their application pro-
   tocol. Examples of such frameworks include GSS-API [GSS] and SASL
   [SASL].

   The generic framework approach has a number of problems. First, it is
   highly susceptible to DOWNGRADE ATTACKS. In a downgrade attack, an
   active attacker tampers with the negotiation in order to force the
   parties to negotiate weaker protection than they otherwise would.
   It's possible to include an integrity check after the negotiation and
   key establishment have both completed, but the strength of this
   integrity check is necessarily limited to the weakest common algo-
   rithm. This problem exists with any negotiation approach, but generic
   frameworks exacerbate it by encouraging the application protocol
   author to just specify the framework rather than think hard about the
   appropriate underlying mechanisms, particularly since the mechanisms
   can very widely in the degree of security offered.




Rescorla, Korver                                                [Page 14]

Internet-Draft     Security Considerations Guidelines


   Another problem is that it's not always obvious how the various secu-
   rity features in the framework interact with the application layer
   protocol. For instance, SASL can be used merely as an authentication
   framework--in which case the SASL exchange occurs but the rest of the
   connection is unprotected, but can also negotiate traffic protection,
   such as via GSS. as a mechanism. Knowing under what circumstances
   traffic protection is optional and which it is required requires
   thinking about the threat model.

   In general, authentication frameworks are most useful in situations
   where users have a wide variety of credentials that must all be acco-
   modated by some service. 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 simplic-
   ity 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 sig-
   nature as proof that the signing party at one point agreed to the
   disputed message. Unfortunately, this approach is insufficient.

   The easiest way for the signing party to repudiate the message is by
   claiming that his private key has been compromised and that some
   attacker (though not necessarily the relying party) signed the dis-
   puted message. In order to defend against this attack the relying
   party needs to demonstrate that the signing party's key had not been
   compromised at the time of the signature. This requires substantial
   infrastructure, including archival storage of certificate revocation
   information and timestamp servers to establish the time that the mes-
   sage was signed.

   Additionally, the relying party might attempt to trick the signing
   party into signing one message while thinking he's signing another.
   This problem is particularly severe when the relying party controls
   the infrastructure that the signing party uses for signing, such as
   in kiosk situations. In many such situations the signing party's key
   is kept on a smartcard but the message to be signed is displayed by
   the relying party.





Rescorla, Korver                                                [Page 15]

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

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

4.4.1. Access Control Lists

   One common form of authorization mechanism is an access control list
   (ACL) that lists users that are permitted access to a resource. Since
   assigning individual authorization permissions to each resource is
   tedious, often resources are hierarchically arranged such that the
   parent resource's ACL is inherited by child resources. This allows
   administrators to set top level policies and override them when nec-
   essary.

4.4.2. Certificate Based Systems

   While the distinction between authentication and authorization is
   intuitive when using simple authentication mechanisms such as user-
   name and password (i.e., everyone understands the difference between
   the administrator account and a user account), with more complex
   authentication mechanisms the distinction is sometimes lost.

   With certificates, for instance, presenting a valid signature does
   not imply authorization. The signature must be backed by a
   certificate chain that contains a trusted root, and that root must be
   trusted in the given context. For instance, users who possess cer-
   tificates issued by the Acme MIS CA may have different web access
   privileges than users who possess certificates issued by the Acme
   Accounting CA, even though both 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



Rescorla, Korver                                                [Page 16]

Internet-Draft     Security Considerations Guidelines


   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 sep-
   arate "Attribute Certificate".

4.5. Providing Traffic Security

   Securely designed protocols should provide some mechanism for secur-
   ing (meaning integrity protecting, authenticating, and possibly
   encrypting) all sensitive traffic. One approach is to secure the pro-
   tocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this
   provides 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 transmis-
   sion security for all traffic between two hosts. The IPsec protocols
   support varying granularities of user identification, including for
   example "IP Subnet", "IP Address", "Fully Qualified Domain Name", and
   individual user ("Mailbox name"). These varying levels of identifica-
   tion 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.

   The primary obstacle to using IPsec to secure other protocols is
   deployment. The major use of IPsec at present is for VPN applica-
   tions, especially for remote network access. Without extremely tight
   coordination between security administrators and application develop-
   ers, VPN usage 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



Rescorla, Korver                                                [Page 17]

   system generally involves changing the operating system, either by
   modifying with the kernel or installing new drivers. This is a sub-
   stantially greater undertaking than simply installing a new applica-
   tion. 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 imple-
   ment. 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 proto-
   col designers SHOULD not assume it will be present. [USEIPSEC] pro-
   vides quite a bit of guidance on when IPsec is a good choice.

4.5.2. SSL/TLS

   The currently most common approach is to use SSL or its successor
   TLS. They provide channel security for a TCP connection at the appli-
   cation level. That is, they run over TCP. SSL implementations typi-
   cally 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.

   The two primary approaches used are to 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 negoti-
   ation 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 protocl such as TCP or SCTP.
   This produces two notable difficulties. First, it cannot be used to
   secure datagram protocols that use UDP. Second, TLS is susceptible 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



Rescorla, Korver                                                [Page 18]

Internet-Draft     Security Considerations Guidelines


   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 con-
   trast, if IPsec were being used, such a forged RST could be rejected
   without affecting the TCP conection. If forged RSTs or other such
   attacks on the TCP connection are 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 to 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 previ-
   ously 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 (remem-
   ber we're not authenticating the server, which is what ordinarily
   prevents this attack) and then simply proxies the SASL handshake.
   From then on, it's as if the connection were in the clear, at least
   as far as that attacker is concerned. In order to prevent this
   attack, the client needs to verify the server's certificate.

   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



Rescorla, Korver                                                [Page 19]

   subject to the layering attacks described above.

4.5.3. Remote Login

   In some special cases it may be worth providing channel-level secu-
   rity directly in 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 pro-
   viding 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.

   However, not all denial of service attacks are equal and more impor-
   tantly, it is possible to design protocols such that denial of ser-
   vice 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 eco-
   nomically. 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.




Rescorla, Korver                                                [Page 20]

Internet-Draft     Security Considerations Guidelines


   Authors of internet standards MUST describe which denial of service
   attacks their protocol is susceptable 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 must use his own IP address.
   Either provides an opportunity for 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 pre-
   vent 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 accom-
   plished 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 zom-
   bies often appear to be making legitimate protocol requests and sim-
   ply 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 launch-
   ing 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].



Rescorla, Korver                                                [Page 21]

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

   A blind attack can be subverted by forcing the attack 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 there-
   fore using a large number of forged source addresses).

4.6.5. Example: Photuris

   [PHOTURIS] specifies an anti-clogging mechanism that prevents attacks
   on Photuris that resemble the SYN flood attack. Photuris employs 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 re-generated 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 secu-
   rity and channel security. Object security refers to security mea-
   sures which apply to entire data objects. Channel security measures
   provide a secure channel over which objects may be carried transpar-
   ently but the channel has no special knowledge about object bound-
   aries.



Rescorla, Korver                                                [Page 22]

Internet-Draft     Security Considerations Guidelines


   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 mes-
   sages 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 indi-
   vidually 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
   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 secu-
   rity 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.





Rescorla, Korver                                                [Page 23]

   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 increas-
   ingly 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 them. Part of the purpose of the Security Considerations
   section is to explain what attacks are out of scope and what counter-
   measures can be applied to defend against them.

   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 foresee-
   able risks and threats to potential implementers and users.

   Authors MUST describe

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


   At least the following forms of attack MUST be considered: eavesdrop-
   ping, 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 mecha-
   nisms, it should be clearly indicated which portions of the data are
   protected and what the protections are (i.e. integrity only, confi-
   dentiality, and/or endpoint authentication, etc.). Some indication
   should also be given to what sorts of attacks the cryptographic pro-
   tection 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.



Rescorla, Korver                                                [Page 24]

Internet-Draft     Security Considerations Guidelines


   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 con-
      tents 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
   services are expected to provide MUST be clearly specified. In addi-
   tion, 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 pro-
   tocol.

   The threat environment addressed by the Security Considerations sec-
   tion MUST at a minimum include deployment across the global Internet
   across multiple administrative boundaries without assuming that fire-
   walls are in place, even if only to provide justification for why
   such consideration is out of scope for the protocool. 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 proto-
   col (e.g. IPsec is useless if key management has been compromised),



Rescorla, Korver                                                [Page 25]

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

   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 sec-
   tions, intended to give the reader a flavor of what's intended by
   this document.

   The first example is a 'retrospective' example, applying the criteria
   of this document to a historical document, RFC-821. The second exam-
   ple 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 docu-
   ment (with new section numbers). Our comments are indented and pref-
   aced with 'NOTE:'. We also add a number of new sections to cover top-
   ics 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. Conse-
   quently, as knowledge of Internet mail increases, so does the knowl-
   edge 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



Rescorla, Korver                                                [Page 26]

Internet-Draft     Security Considerations Guidelines


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


   Various protocol extensions and configuration options that provide
   authentication at the transport level (e.g., from an SMTP client to
   an SMTP server) improve somewhat on the traditional situation
   described above. However, unless they are accompanied by careful
   handoffs of responsibility in a carefully-designed trust environment,
   they remain inherently weaker than end-to-end mechanisms which use
   digitally signed messages rather than depending on the integrity of
   the transport system.

   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 applica-
   tions 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 protec-
   tion 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.

   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 appear-
   ance 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



Rescorla, Korver                                                [Page 27]

   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
   to alter the headers of the message for delivery. The popular "Appar-
   ently-to" header is a violation of this principle as well as a common
   source of unintended information disclosure and SHOULD NOT be used.

6.1.1.3. VRFY, EXPN, 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 com-
   mand 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 confor-
   mance.

   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 adminis-
   trators 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 authenti-
   cation mechanisms are introduced into SMTP, some sites may choose to
   make EXPN available only to authenticated requestors.


     NOTE: It's not clear that disabling VRFY adds much protection,
     since it's possible to discover whether an address is valid
     using RCPT TO.







Rescorla, Korver                                                [Page 28]

Internet-Draft     Security Considerations Guidelines


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 infor-
   mation that might be useful in a potential hostile attack. The util-
   ity of the debugging information is beyond doubt. Those who argue for
   making it available point out that it is far better to actually
   secure an SMTP server rather than hope that trying to conceal known
   vulnerabilities by hiding the server's precise identity will provide
   more protection. Sites are encouraged to evaluate the tradeoff with
   that issue in mind; implementations are strongly encouraged to mini-
   mally 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 nor-
   mally 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 inadver-
   tently 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 inad-
   vertently 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 exces-
   sive advantage of the right to reject traffic, the ubiquity of email
   availability (one of the strengths of the Internet) will be threat-
   ened; considerable care should be taken and balance maintained if a
   site decides to be selective about the traffic it will accept and
   process.




Rescorla, Korver                                                [Page 29]

   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 func-
   tion 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.

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 per-
   spective, spam is indistinguishable from other e-mail--the distinc-
   tion 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 refus-
   ing 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 offend-
   ers (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 adver-
   tise 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].






Rescorla, Korver                                                [Page 30]

Internet-Draft     Security Considerations Guidelines


6.1.1.8.2. Endpoints [NEW]

   Realistically, SMTP endpoints cannot refuse to deny service to unau-
   thenticated senders. Since the vast majority of senders are unauthen-
   ticated, this would break Internet mail interoperability. The excep-
   tion to this is when the endpoint server should only be receiving
   mail from some other server which can itself receive unauthenticated
   messages. For instance, a company might operate a public gateway but
   configure its internal servers to only talk to the gateway.

6.1.2. Communications security issues

   SMTP itself provides no communications security, and therefore a
   large number of attacks are possible. A passive attack is sufficient
   to recover the text of messages transmitted with SMTP. No endpoint
   authentication is provided by the protocol. Sender spoofing is triv-
   ial, and therefore forging email messages is trivial. Some implemen-
   tations do add header lines with hostnames derived through reverse
   name resolution (which is only secure to the extent that it is diffi-
   cult to spoof DNS -- not very), although these header lines are nor-
   mally not displayed to users. Receiver spoofing is also fairly
   straight-forward, either using TCP connection hijacking or DNS spoof-
   ing. Moreover, since email messages often pass through SMTP gateways,
   all intermediate gateways must be trusted, a condition nearly impos-
   sible 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



Rescorla, Korver                                                [Page 31]

   identification is not generally available, since generally only the
   sender's machine is authenticated, not the sender himself. Further-
   more, the identity of the sender simply appears 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.

   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 imple-
   mentation 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 administarors 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 secu-
   rity value, particularly to the extent that confidentiality is pro-
   vided, 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 pro-
   vides 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 con-
   tain a US exportable (and hence low security) mode. Applications
   desiring high security should ensure that this mode is disabled. Pro-
   tection 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 draft 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 send-
   ing 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



Rescorla, Korver                                                [Page 32]

Internet-Draft     Security Considerations Guidelines


   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 confi-
   dentiality is provided, traffic analysis is still possible.

6.1.3. Denial of Service

   None of these security measures provides any real protection against
   denial of service. SMTP connections can easily be used to tie up sys-
   tem resources in a number of ways, including excessive port consump-
   tion, excessive disk usage (email is typically delivered to disk
   files), and excessive memory consumption (sendmail, for instance, is
   fairly large, and typically forks a new process to deal with each
   message.)

   If transport- or application-layer security is used for SMTP connec-
   tions, 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 Proto-
   col ( [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.







Rescorla, Korver                                                [Page 33]

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

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 Authentica-
   tion Header [AH] using [HMAC]. This provides strong protection
   against configuration errors, replay attacks, and packet corrup-
   tion/modification.





Rescorla, Korver                                                [Page 34]

Internet-Draft     Security Considerations Guidelines


   This type of authentication is RECOMMENDED when there is limited con-
   trol 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.

     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. Additionally, there should be
     a required algorithm (HMAC-SHA1)

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

     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.


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



Rescorla, Korver                                                [Page 35]

   Baker. The other primary source for this document is specific com-
   ments received from Steve Bellovin. Early review of this document was
   done by Lisa Dusseault and Mark Schertler. Other useful comments were
   received from Steve Kent, Allison Mankin, and Kurt Zeilenga.

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

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


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

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

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

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

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

   [HMAC]     Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
              for Message Authentication", RFC 2104, February 1997.

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

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

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

   [PKIX]     Housley, R., Ford, W., Polk, W., Solo, D., Internet X.509
              "Public Key Infrastructure Certificate and CRL Profile",
              RFC 2459, January 1999.

   [RFC-2223] Postel J., and Reynolds J., "Instructions to RFC Authors",
              RFC 2223, October 1997.

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



Rescorla, Korver                                                [Page 36]

Internet-Draft     Security Considerations Guidelines


           RFC 2505, February 1999.

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

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

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

   [SSH]      Ylonen, T., "SSH - Secure Login Connections Over 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 TLS",
              RFC 2487, January 1998.

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

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


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

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

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

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

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

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



Rescorla, Korver                                                [Page 37]

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


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

   [EKE]      Bellovin, S., Merritt, M., "Encrypted Key Exchange:
              Password-based protocols secure against dictionary
              attacks", Proceedings of the IEEE Symposium on Research
              in Security and Privacy, May 1992.

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

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

   [IPSPPROB] Bellovin, S. M., "Problem Areas 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 Lapsley, P., "Network News Transfer Protocol",
              RFC 977, February 1986.

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

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

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

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

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



Rescorla, Korver                                                [Page 38]

Internet-Draft     Security Considerations Guidelines


   [USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
           draft-bellovin-useipsec-00.txt, October 2002.
           [Note to RFC editor: I understand that this is going to
           be submitted to BCP Real Soon Now.]

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

Security Considerations

   This entire document is about security considerations.

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

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

Internet Architecture Board <iab@iab.org>
IAB


Appendix A. IAB Members at the time of this writing

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






Rescorla, Korver                                                [Page 39]

                           Table of Contents


1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
1.1. Requirements  . . . . . . . . . . . . . . . . . . . . . . . . .   2
2. The Goals of Security . . . . . . . . . . . . . . . . . . . . . .   2
2.1. Communication Security  . . . . . . . . . . . . . . . . . . . .   2
2.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . . .   2
2.1.2. Data Integrity  . . . . . . . . . . . . . . . . . . . . . . .   2
2.1.3. Peer Entity authentication  . . . . . . . . . . . . . . . . .   3
2.2. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . .   3
2.3. Systems Security  . . . . . . . . . . . . . . . . . . . . . . .   4
2.3.1. Unauthorized Usage  . . . . . . . . . . . . . . . . . . . . .   4
2.3.2. Inappropriate Usage . . . . . . . . . . . . . . . . . . . . .   4
2.3.3. Denial of Service . . . . . . . . . . . . . . . . . . . . . .   5
3. The Internet Threat Model . . . . . . . . . . . . . . . . . . . .   5
3.1. Limited Threat Models . . . . . . . . . . . . . . . . . . . . .   6
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . . . . . .   6
3.2.1. Confidentiality Violations  . . . . . . . . . . . . . . . . .   7
3.2.2. Password Sniffing . . . . . . . . . . . . . . . . . . . . . .   7
3.2.3. Offline Cryptographic Attacks . . . . . . . . . . . . . . . .   7
3.3. Active Attacks  . . . . . . . . . . . . . . . . . . . . . . . .   8
3.3.1. Replay Attacks  . . . . . . . . . . . . . . . . . . . . . . .   8
3.3.2. Message Insertion . . . . . . . . . . . . . . . . . . . . . .   9
3.3.3. Message Deletion  . . . . . . . . . . . . . . . . . . . . . .   9
3.3.4. Message Modification  . . . . . . . . . . . . . . . . . . . .   9
3.3.5. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . . .  10
3.4. Topological Issues  . . . . . . . . . . . . . . . . . . . . . .  11
3.5. On-path versus off-path . . . . . . . . . . . . . . . . . . . .  11
3.6. Link-local  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
4. Common Issues . . . . . . . . . . . . . . . . . . . . . . . . . .  12
4.1. User Authentication . . . . . . . . . . . . . . . . . . . . . .  12
4.1.1. Username/Password . . . . . . . . . . . . . . . . . . . . . .  12
4.1.2. Challenge Response and One Time Passwords . . . . . . . . . .  12
4.1.3. Certificates  . . . . . . . . . . . . . . . . . . . . . . . .  13
4.1.4. Some Uncommon Systems . . . . . . . . . . . . . . . . . . . .  13
4.1.5. Host Authentication . . . . . . . . . . . . . . . . . . . . .  14
4.2. Generic Security Frameworks . . . . . . . . . . . . . . . . . .  14
4.3. Non-repudiation . . . . . . . . . . . . . . . . . . . . . . . .  15
4.4. Authorization vs. Authentication  . . . . . . . . . . . . . . .  16
4.4.1. Access Control Lists  . . . . . . . . . . . . . . . . . . . .  16
4.4.2. Certificate Based Systems . . . . . . . . . . . . . . . . . .  16
4.5. Providing Traffic Security  . . . . . . . . . . . . . . . . . .  17
4.5.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
4.5.2. SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
4.5.2.1. Virtual Hosts . . . . . . . . . . . . . . . . . . . . . . .  19
4.5.2.2. Remote Authentication and TLS . . . . . . . . . . . . . . .  19
4.5.3. Remote Login  . . . . . . . . . . . . . . . . . . . . . . . .  20



Rescorla, Korver                                                [Page 40]

Internet-Draft     Security Considerations Guidelines


4.6. Denial of Service Attacks and Countermeasures . . . . . . . . .  20
4.6.1. Blind Denial of Service . . . . . . . . . . . . . . . . . . .  21
4.6.2. Distributed Denial of Service . . . . . . . . . . . . . . . .  21
4.6.3. Avoiding Denial of Service  . . . . . . . . . . . . . . . . .  21
4.6.3.1. Make your attacker do more work than you do . . . . . . . .  21
4.6.3.2. Make your attacker prove they can receive data from you
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
4.6.4. Example: TCP SYN Floods . . . . . . . . . . . . . . . . . . .  22
4.6.5. Example: Photuris . . . . . . . . . . . . . . . . . . . . . .  22
4.7. Object vs. Channel Security . . . . . . . . . . . . . . . . . .  22
4.8. Firewalls and Network Topology  . . . . . . . . . . . . . . . .  23
5. Writing Security Considerations Sections  . . . . . . . . . . . .  24
6. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  26
6. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  26
6.1. SMTP  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  26
6.1.1. Security Considerations . . . . . . . . . . . . . . . . . . .  26
6.1.1.1. Mail Security and Spoofing  . . . . . . . . . . . . . . . .  26
6.1.1.2. 'Blind' Copies  . . . . . . . . . . . . . . . . . . . . . .  27
6.1.1.3. VRFY, EXPN, and Security  . . . . . . . . . . . . . . . . .  28
6.1.1.4. Information Disclosure in Announcements . . . . . . . . . .  29
6.1.1.5. Information Disclosure in Trace Fields  . . . . . . . . . .  29
6.1.1.6. Information Disclosure in Message Forwarding  . . . . . . .  29
6.1.1.7. Scope of Operation of SMTP Servers  . . . . . . . . . . . .  29
6.1.1.8. Inappropriate Usage [NEW] . . . . . . . . . . . . . . . . .  30
6.1.1.8.1. Closed Relaying [NEW] . . . . . . . . . . . . . . . . . .  30
6.1.1.8.2. Endpoints [NEW] . . . . . . . . . . . . . . . . . . . . .  31
6.1.2. Communications security issues  . . . . . . . . . . . . . . .  31
6.1.2.1. SMTP over IPSEC [NEW] . . . . . . . . . . . . . . . . . . .  31
6.1.2.2. SMTP/TLS [NEW]  . . . . . . . . . . . . . . . . . . . . . .  32
6.1.2.3. S/MIME and PGP/MIME [NEW] . . . . . . . . . . . . . . . . .  32
6.1.3. Denial of Service . . . . . . . . . . . . . . . . . . . . . .  33
6.2. VRRP  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  33
6.2.1. Security Considerations . . . . . . . . . . . . . . . . . . .  33
6.2.1.1. No Authentication . . . . . . . . . . . . . . . . . . . . .  34
6.2.1.2. Simple Text Password  . . . . . . . . . . . . . . . . . . .  34
6.2.1.3. IP Authentication Header  . . . . . . . . . . . . . . . . .  34
6.2.1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  35
6.2.1.3. Normative References  . . . . . . . . . . . . . . . . . . .  36
6.2.1.3. Informative References  . . . . . . . . . . . . . . . . . .  38
Security Considerations  . . . . . . . . . . . . . . . . . . . . . .  39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  39










Rescorla, Korver                                                [Page 41]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/