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

Versions: 00 01 03 04 05

                                                             E. Rescorla
                                                              RTFM, Inc.
                                                               B. Korver
INTERNET-DRAFT                                           Network Alchemy
<draft-rescorla-sec-cons-00.txt>           October 1999 (Expires April 2000)

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

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.


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

1.  Introduction

   All RFCs are required by [RFC1543] 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
   is a series of examples.

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.

Rescorla, Korver                                                 [Page 1]

Internet-Draft     Security Considerations Guidelines

   We can loosely divide security goals into those related to protecting
   communications (COMMUNICATIONS SECURITY) and those relating to pro-
   tecting systems (SYSTEMS SECURITY). Since communications are carried
   out by systems and access to systems is through communications chan-
   nels, these goals obviously interlock, but they can also be indepen-
   dently provided.

2.1.  Communications Security

   Different authors partition the goals of communications security dif-
   ferently. The partitioning we've found most useful is to divide them
   into three major categories: CONFIDENTIALITY, MESSAGE INTEGRITY and
   ENDPOINT 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
   the government taps your phone, that poses a risk to your confiden-
   tiality.

   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.  Message Integrity

   The second primary goal is MESSAGE INTEGRITY. The basic idea here is
   that we want to be sure that the message we receive is the one that
   the sender sent. In paper-based systems, some message integrity comes
   automatically. When you receive a letter written in pen you can be
   fairly certain that no words have been removed by an attacker because
   pen marks are difficult to remove from paper. However, an attacker
   could have easily added some marks to the paper and completely
   changed the meaning of the message. Similarly, it's easy to shorten
   the page to truncate the message.

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

Rescorla, Korver                                                 [Page 2]

Internet-Draft     Security Considerations Guidelines

2.1.3.  Endpoint authentication

   The third property we're concerned with is ENDPOINT AUTHENTICATION.
   What we mean by this is that we know that one of the endpoints in the
   communication is the one we intended.  Without endpoint authentica-
   tion, it's very difficult to provide either confidentiality or mes-
   sage integrity.  For instance, if we receive a message from Alice,
   the property of message integrity doesn't do us much good unless we
   know that it was in fact sent by Alice and not the attacker. Simi-
   larly, 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 endpoint 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.

   On the other hand, cash is an example of sender authentication. A
   dollar bill is like a message signed by the government.  The govern-
   ment has no idea who's got any given dollar bill but you can be
   fairly certain that any bill was actually printed by the US Mint
   because currency is difficult to forge.

2.2.  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.2.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.

Rescorla, Korver                                                 [Page 3]

Internet-Draft     Security Considerations Guidelines

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

2.2.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 assumed 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

Rescorla, Korver                                                 [Page 4]

Internet-Draft     Security Considerations Guidelines

   environment provides no assurance that packets which claim to be from
   that system in fact are.

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

3.1.  Limited Threat Models

   As we've said, a resourceful and dedicated attacker can control the
   entire communications channel. However, a large number of attacks can
   be mounted by an attacker with fewer resources.  A number of cur-
   rently known attacks can be mounted by an attacker with limited con-
   trol 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.

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

Rescorla, Korver                                                 [Page 5]

Internet-Draft     Security Considerations Guidelines

   Wireless communications channels deserve special consideration.
   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.

   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.  Privacy 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 [REF], POP [REF], and NNTP [REF],
   use a shared password to authenticate the client to the server.  Fre-
   quently, this password is transmitted from the client to the server
   in the clear over the communications channel. An attacker who can
   read this traffic can therefore capture the password and REPLAY it.
   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 SEARCH. The
   attacker captures a challenge-response pair and then proceeds to try
   dictionary words until he finds a password that produces the right

Rescorla, Korver                                                 [Page 6]

Internet-Draft     Security Considerations Guidelines

   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 [REF: Crack].  When NIS
   is used, the crypted password is transmitted over the local network
   and an attacker can thus sniff the password and attack it.

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

3.3.  Active Attacks

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

   Under certain circumstances, such a packet may be screened out by the
   network. For instance, many packet filtering firewalls screen out all
   packets with source addresses on the INTERNAL network that arrive on
   the EXTERNAL interface. Note, however, that this provides no 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 [REF] can be mounted
   successfully without disguising the sender's address. However, it is
   common practice to disguise one's address in order to conceal one's
   identity if an attack is discovered.

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

Rescorla, Korver                                                 [Page 7]

Internet-Draft     Security Considerations Guidelines

3.3.1.  Replay Attacks

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

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

3.3.2.  Message Insertion

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

   For example, a denial-of-service attack can be mounted by inserting a
   series of spurious TCP SYN packets [REF] 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 [REF] often requires
   a message deletion attack to be performed successfully. In this blind
   attack, the host whose address is being forged will receive a spuri-
   ous 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.

Rescorla, Korver                                                 [Page 8]

Internet-Draft     Security Considerations Guidelines

3.3.4.  Message Modification

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

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

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 client/server pro-
   tocol lacks MUTUAL ENDPOINT AUTHENTICATION. For instance, if an
   attacker can hijack the client TCP connection during the TCP hand-
   shake (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.

4.  Common Issues

   Although each system's security requirements are unique, certain com-
   mon requirements appear in a number of protocols. Often, naive proto-
   col designers are faced with these requirements, they choose an obvi-
   ous but insecure solution even though better solutions are available.
   This section describes a number of issues seen in many protocols and

Rescorla, Korver                                                 [Page 9]

Internet-Draft     Security Considerations Guidelines

   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 across 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.) Secure-ID is a
   variant of this scheme. In a challenge-response scheme, the host and
   the user share some secret (which often is represented as a pass-
   word). In order to authenticate the user, the host presents the user
   with a (randomly generated) challenge. The user computes some func-
   tion based on the challenge and the secret and provides that to the
   host, which verifies it. Often this computation is performed in a
   handheld device, such as a DES Gold card.

   Both types of scheme provide protection against replay attack, but
   often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of 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
   rather than just random strings.

Rescorla, Korver                                                [Page 10]

Internet-Draft     Security Considerations Guidelines

   These systems are also often vulnerable to an active attack.  Unless
   communications 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]. 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], [SRP2]) allow one to securely bootstrap a
   user's password into a shared key which can be used as input to a
   cryptographic protocol.  Similarly, the user can authenticate using
   public key certificates. (e.g. S-HTTP client authentication). Typi-
   cally these methods are used as part of a more complete security pro-
   tocol.

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 [REF]. When requesting such a service, one has
   ensure that the entity that one is talking to not only has a certifi-
   cate but that that certificate corresponds to the expected identity
   of the server. The important thing to have is a secure binding
   between the certificate and the expected hostname.

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

Rescorla, Korver                                                [Page 11]

Internet-Draft     Security Considerations Guidelines

4.2.  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.  Per-
   haps because of this tight coupling, authentication is sometimes mis-
   takenly thought to imply authorization.  Authentication simply iden-
   tifies a party, authorization defines whether they can perform a cer-
   tain action.

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

4.2.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.2.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 certifi-
   cate 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 attack poli-
   cies 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

Rescorla, Korver                                                [Page 12]

Internet-Draft     Security Considerations Guidelines

   separate "Attribute Certificate".

4.3.  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 Secure DNS [REF], S/MIME [REF] or S-HTTP [REF].
   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
   [REF] and SSL/TLS [REF].

4.3.1.  IPSEC

   When used, IPSEC can provide security for all traffic between two
   hosts. When working, IPSEC is transparent to the programmer who can
   issue ordinary networking calls as usual.  The primary problem with
   IPSEC is deployment. In general, it must be implemented directly in
   the operating system protocol stack and many operating systems don't
   have it. Note the following tradeoff: because IPSec happens at the IP
   layer, important security information (such as identity) is often not
   available to the protocol.

4.3.2.  SSL/TLS

   The currently most common approach is to use SSL or it's 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) [REF]
   or to have a mechanism for negotiating upward from the base protocol
   to TLS. [REF: SMTP/TLS, HTTP Upgrade] When an upward negotiation
   strategy is used, care must be taken to ensure that an attacker can
   not force a clear connection when both parties wish to use TLS.

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

Rescorla, Korver                                                [Page 13]

Internet-Draft     Security Considerations Guidelines

   provide a secure channel over which objects may be carried transpar-
   ently but the channel has no special knowledge about object bound-
   aries.

   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.

   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 pro-
   vides 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.

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

Rescorla, Korver                                                [Page 14]

Internet-Draft     Security Considerations Guidelines

     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. If the protocol incorporates cryptographic protection
   mechanisms, it should be clearly indicated which portions of the data
   are protected and what the protections are (i.e. integrity only, con-
   fidentiality, 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.
   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.

   The threat environment addressed by the Security Considerations sec-
   tion MUST at a minimum include deployment across the global Internet

Rescorla, Korver                                                [Page 15]

Internet-Draft     Security Considerations Guidelines

   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),
   from incorrect implementation, compromise of the security technology
   used for risk reduction (e.g. 40-bit DES), 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.  Had that
   document been written today, the Security Considerations section
   might look something like this:

6.1.1.  SMTP Security Considerations

   SMTP as-is provides no security precautions of any kind. All the
   attacks we are about to describe must be provided by a different pro-
   tocol layer.

Rescorla, Korver                                                [Page 16]

Internet-Draft     Security Considerations Guidelines

   A passive attack is sufficient to recover message text. 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.1.1.  SMTP over IPSEC

   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.  No sender
   identification is available, since the sender's machine is authenti-
   cated, not the sender himself. Furthermore, the identity of the
   sender simply appears in the From header of the message, so it is
   easily spoofable by the sender. Finally, unless the security policy
   is set extremely strictly, there is also an active downgrade to
   cleartext attack.

6.1.1.2.  SMTP/TLS

   SMTP can be combined with TLS as described in [SMTPTLS]. 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

Rescorla, Korver                                                [Page 17]

Internet-Draft     Security Considerations Guidelines

   contain a US exportable (and hence low security) mode. Applications
   desiring high security should ensure that this mode is disabled.
   Protection is provided against replay attacks, since the data itself
   is protected and the packets cannot be replayed.  [note: The Security
   Considerations section of the SMTP over TLS draft is quite good and
   bears reading as an example of how to do things.]

6.1.1.3.  S/MIME and PGP/MIME

   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
   obtained.  Note, however, that no protection is provided against
   replay attacks.

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

6.1.1.5.  Inappropriate Usage

   In particular, there is no protection provided against unsolicited
   mass email (aka SPAM).

   SMTP also includes several commands which may be used by attackers to
   explore the machine on which the SMTP server runs. The VRFY command
   permits an attacker to convert user-names to mailbox name and often
   real name. This is often useful in mounting a password guessing
   attack, as many users use their name as their password.  EXPN permits
   an attacker to expand an email list to the names of the subscribers.
   This may be used in order to generate a list of legitimate users in
   order to attack their accounts, as well as to build mailing lists for
   future SPAM. Administrators may choose to disable these commands.

6.2.  VRRP

   The second example is from VRRP, the Virtual Router Redundance Proto-
   col ([RFC2388]). We reproduce here the Security Considerations

Rescorla, Korver                                                [Page 18]

Internet-Draft     Security Considerations Guidelines

   section from that document (with new section numbers).  Our comments
   are indented and prefaced with 'NOTE:'.

6.2.1.  Security Considerations

   VRRP is designed for a range of internetworking environments that may
   employ different security policies.  The protocol includes several
   authentication methods ranging from no authentication, simple clear
   text passwords, and strong authentication using IP Authentication
   with MD5 HMAC.  The details on each approach including possible
   attacks and recommended environments follows.

   Independent of any authentication type VRRP includes a mechanism
   (setting TTL=255, checking on receipt) that protects against VRRP
   packets being injected from another remote network.  This limits most
   vulnerabilities to local attacks.

     NOTE: The security measures discussed in the following sections
     only provide various kinds of authentication. No confidentiality
     is provided at all. This should be explicitly described as outside
     the scope.

6.2.1.1.  No Authentication

   The use of this authentication type means that VRRP protocol
   exchanges are not authenticated.  This type of authentication SHOULD
   only be used in environments were there is minimal security risk and
   little chance for configuration errors (e.g., two VRRP routers on a
   LAN).

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

Rescorla, Korver                                                [Page 19]

Internet-Draft     Security Considerations Guidelines

   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.

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 [AUTH] using "The Use of HMAC-MD5-96 within ESP and AH",
   [HMAC].  This provides strong protection against configuration
   errors, replay attacks, and packet corruption/modification.

   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: Specifically, although securing VRRP prevents unauthorized
machines
     from taking part in the election protocol, it does not protect
     hosts on the network from being deceived.  For example, a gratutitous
     ARP reply from what purports to be the virtual router's IP address
     can redirect traffic to an unauthorized machine.  Similarly,
     individual connections can be diverted by means of forged ICMP
     Redirect messages.

Acknowledgments

   This document is heavily based on a note written by Ran Atkinson in
   1997. That note was written after the IAB Security Workshop held in
   early 1997, based on input from everyone at that workshop. Some of
   the specific text above was taken from Ran's original document, and
   some of that text was taken from an email message written by Fred
   Baker.

   The other primary source for this document is specific comments
   received from Steve Bellovin. Early review of this document was done
   by Lisa Dusseault and Mark Schertler.

References
   [CA-96.21] "TCP SYN Flooding and IP Spoofing", CERT Advisory CA-96.21
     ftp://info.cert.org/pub/cert advisories/CA-96.21.tcp syn flooding

The rest are TBD

Rescorla, Korver                                                [Page 20]

Internet-Draft     Security Considerations Guidelines

Security Considerations

   This entire document is about security considerations.

Author's Address
Eric Rescorla <ekr@rtfm.com>
RTFM, Inc.
30 Newell Road #16
East Palo Alto, CA 94303
Phone: (650) 328-8631

Brian Korver <briank@network-alchemy.com>
Network Alchemy
1538 Pacific Avenue
Santa Cruz, CA  95060
Phone: (831)-460-3800

Rescorla, Korver                                                [Page 21]

Internet-Draft     Security Considerations Guidelines

                           Table of Contents

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   1
2. The Goals of Security . . . . . . . . . . . . . . . . . . . . . .   1
2.1. Communications Security . . . . . . . . . . . . . . . . . . . .   2
2.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . . .   2
2.1.2. Message Integrity . . . . . . . . . . . . . . . . . . . . . .   2
2.1.3. Endpoint authentication . . . . . . . . . . . . . . . . . . .   3
2.2. Systems Security  . . . . . . . . . . . . . . . . . . . . . . .   3
2.2.1. Unauthorized Usage  . . . . . . . . . . . . . . . . . . . . .   3
2.2.2. Inappropriate Usage . . . . . . . . . . . . . . . . . . . . .   4
2.2.3. Denial of Service . . . . . . . . . . . . . . . . . . . . . .   4
3. The Internet Threat Model . . . . . . . . . . . . . . . . . . . .   4
3.1. Limited Threat Models . . . . . . . . . . . . . . . . . . . . .   5
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . . . . . .   5
3.2.1. Privacy Violations  . . . . . . . . . . . . . . . . . . . . .   6
3.2.2. Password Sniffing . . . . . . . . . . . . . . . . . . . . . .   6
3.2.3. Offline Cryptographic Attacks . . . . . . . . . . . . . . . .   6
3.3. Active Attacks  . . . . . . . . . . . . . . . . . . . . . . . .   7
3.3.1. Replay Attacks  . . . . . . . . . . . . . . . . . . . . . . .   8
3.3.2. Message Insertion . . . . . . . . . . . . . . . . . . . . . .   8
3.3.3. Message Deletion  . . . . . . . . . . . . . . . . . . . . . .   8
3.3.4. Message Modification  . . . . . . . . . . . . . . . . . . . .   9
3.3.5. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . . .   9
4. Common Issues . . . . . . . . . . . . . . . . . . . . . . . . . .   9
4.1. User Authentication . . . . . . . . . . . . . . . . . . . . . .  10
4.1.1. Username/Password . . . . . . . . . . . . . . . . . . . . . .  10
4.1.2. Challenge Response and One Time Passwords . . . . . . . . . .  10
4.1.3. Certificates  . . . . . . . . . . . . . . . . . . . . . . . .  11
4.1.4. Some Uncommon Systems . . . . . . . . . . . . . . . . . . . .  11
4.1.5. Host Authentication . . . . . . . . . . . . . . . . . . . . .  11
4.2. Authorization vs. Authentication  . . . . . . . . . . . . . . .  12
4.2.1. Access Control Lists  . . . . . . . . . . . . . . . . . . . .  12
4.2.2. Certificate Based Systems . . . . . . . . . . . . . . . . . .  12
4.3. Providing Traffic Security  . . . . . . . . . . . . . . . . . .  13
4.3.1. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
4.3.2. SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
4.4. Object vs. Channel Security . . . . . . . . . . . . . . . . . .  13
5. Writing Security Considerations Sections  . . . . . . . . . . . .  14
6. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
6. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
6.1. SMTP  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
6.1.1. SMTP Security Considerations  . . . . . . . . . . . . . . . .  16
6.1.1.1. SMTP over IPSEC . . . . . . . . . . . . . . . . . . . . . .  17
6.1.1.2. SMTP/TLS  . . . . . . . . . . . . . . . . . . . . . . . . .  17
6.1.1.3. S/MIME and PGP/MIME . . . . . . . . . . . . . . . . . . . .  18
6.1.1.4. Denial of Service . . . . . . . . . . . . . . . . . . . . .  18

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

6.1.1.5. Inappropriate Usage . . . . . . . . . . . . . . . . . . . .  18
6.2. VRRP  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
6.2.1. Security Considerations . . . . . . . . . . . . . . . . . . .  19
6.2.1.1. No Authentication . . . . . . . . . . . . . . . . . . . . .  19
6.2.1.2. Simple Text Password  . . . . . . . . . . . . . . . . . . .  19
6.2.1.3. IP Authentication Header  . . . . . . . . . . . . . . . . .  20
6.2.1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  20
6.2.1.3. References  . . . . . . . . . . . . . . . . . . . . . . . .  20
Security Considerations  . . . . . . . . . . . . . . . . . . . . . .  21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  21


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/