Movatterモバイル変換

Network Working Group                                        E. RescorlaRequest for Comments: 3552                                    RTFM, Inc.BCP: 72                                                        B. KorverCategory: Best Current Practice                          Xythos Software                                             Internet Architecture Board                                                                     IAB                                                               July 2003Guidelines for Writing RFC Text on Security ConsiderationsStatus of this Memo   This document specifies an Internet Best Current Practices for the   Internet Community, and requests discussion and suggestions for   improvements.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2003).  All Rights Reserved.Abstract   All RFCs are required to have a Security Considerations section.   Historically, such sections have been relatively weak.  This document   provides guidelines to RFC authors on how to write a good Security   Considerations section.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . .31.1. Requirements. . . . . . . . . . . . . . . . . . . . .32. The Goals of Security. . . . . . . . . . . . . . . . . . .32.1. Communication Security. . . . . . . . . . . . . . . .32.1.1. Confidentiality. . . . . . . . . . . . . . . .42.1.2. Data Integrity . . . . . . . . . . . . . . . .42.1.3. Peer Entity authentication . . . . . . . . . .42.2. Non-Repudiation . . . . . . . . . . . . . . . . . . .52.3. Systems Security. . . . . . . . . . . . . . . . . . .52.3.1. Unauthorized Usage . . . . . . . . . . . . . .62.3.2. Inappropriate Usage. . . . . . . . . . . . . .62.3.3. Denial of Service. . . . . . . . . . . . . . .63. The Internet Threat Model. . . . . . . . . . . . . . . . .63.1. Limited Threat Models . . . . . . . . . . . . . . . .73.2. Passive Attacks . . . . . . . . . . . . . . . . . . .73.2.1. Confidentiality Violations . . . . . . . . . .83.2.2. Password Sniffing. . . . . . . . . . . . . . .83.2.3. Offline Cryptographic Attacks. . . . . . . . .9Rescorla & Korver        Best Current Practice                  [Page 1]

RFC 3552           Security Considerations Guidelines          July 20033.3. Active Attacks. . . . . . . . . . . . . . . . . . . .93.3.1. Replay Attacks . . . . . . . . . . . . . . . .103.3.2. Message Insertion. . . . . . . . . . . . . . .103.3.3. Message Deletion . . . . . . . . . . . . . . .113.3.4. Message Modification . . . . . . . . . . . . .113.3.5. Man-In-The-Middle. . . . . . . . . . . . . . .123.4. Topological Issues. . . . . . . . . . . . . . . . . .123.5. On-path versus off-path . . . . . . . . . . . . . . .133.6. Link-local. . . . . . . . . . . . . . . . . . . . . .134. Common Issues. . . . . . . . . . . . . . . . . . . . . . .134.1. User Authentication . . . . . . . . . . . . . . . . .144.1.1. Username/Password. . . . . . . . . . . . . . .144.1.2. Challenge Response and One Time Passwords. . .144.1.3. Shared Keys. . . . . . . . . . . . . . . . . .154.1.4. Key Distribution Centers . . . . . . . . . . .154.1.5. Certificates . . . . . . . . . . . . . . . . .154.1.6. Some Uncommon Systems. . . . . . . . . . . . .154.1.7. Host Authentication. . . . . . . . . . . . . .164.2. Generic Security Frameworks . . . . . . . . . . . . .164.3. Non-repudiation . . . . . . . . . . . . . . . . . . .174.4. Authorization vs. Authentication. . . . . . . . . . .184.4.1. Access Control Lists . . . . . . . . . . . . .184.4.2. Certificate Based Systems. . . . . . . . . . .184.5. Providing Traffic Security. . . . . . . . . . . . . .194.5.1. IPsec. . . . . . . . . . . . . . . . . . . . .194.5.2. SSL/TLS. . . . . . . . . . . . . . . . . . . .204.5.3. Remote Login . . . . . . . . . . . . . . . . .224.6. Denial of Service Attacks and Countermeasures . . . .224.6.1. Blind Denial of Service. . . . . . . . . . . .234.6.2. Distributed Denial of Service. . . . . . . . .234.6.3. Avoiding Denial of Service . . . . . . . . . .244.6.4. Example: TCP SYN Floods. . . . . . . . . . . .244.6.5. Example: Photuris. . . . . . . . . . . . . . .254.7. Object vs. Channel Security . . . . . . . . . . . . .254.8. Firewalls and Network Topology. . . . . . . . . . . .265. Writing Security Considerations Sections . . . . . . . . .266. Examples . . . . . . . . . . . . . . . . . . . . . . . . .286.1. SMTP. . . . . . . . . . . . . . . . . . . . . . . . .296.1.1. Security Considerations. . . . . . . . . . . .296.1.2. Communications security issues . . . . . . . .346.1.3. Denial of Service. . . . . . . . . . . . . . .366.2. VRRP. . . . . . . . . . . . . . . . . . . . . . . . . .366.2.1. Security Considerations. . . . . . . . . . . .367. Acknowledgments. . . . . . . . . . . . . . . . . . . . . .388. Normative References . . . . . . . . . . . . . . . . . . .399. Informative References . . . . . . . . . . . . . . . . . .41   10.Security Considerations. . . . . . . . . . . . . . . . . .42Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . .43Rescorla & Korver        Best Current Practice                  [Page 2]

RFC 3552           Security Considerations Guidelines          July 2003   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .43   Full Copyright Statement. . . . . . . . . . . . . . . . . . .441. Introduction   All RFCs are required byRFC 2223 to contain a Security   Considerations section.  The purpose of this is both to encourage   document authors to consider security in their designs and to inform   the reader of relevant security issues.  This memo is intended to   provide guidance to RFC authors in service of both ends.   This document is structured in three parts.  The first is a   combination security tutorial and definition of common terms; the   second is a series of guidelines for writing Security Considerations;   the third is a series of examples.1.1. Requirements   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described inBCP 14,RFC 2119   [KEYWORDS].2. The Goals of Security   Most people speak of security as if it were a single monolithic   property of a protocol or system, however, upon reflection, one   realizes that it is clearly not true.  Rather, security is a series   of related but somewhat independent properties.  Not all of these   properties are required for every application.   We can loosely divide security goals into those related to protecting   communications (COMMUNICATION SECURITY, also known as COMSEC) and   those relating to protecting systems (ADMINISTRATIVE SECURITY or   SYSTEM SECURITY).  Since communications are carried out by systems   and access to systems is through communications channels, these goals   obviously interlock, but they can also be independently provided.2.1. Communication Security   Different authors partition the goals of communication security   differently.  The partitioning we've found most useful is to divide   them into three major categories: CONFIDENTIALITY, DATA INTEGRITY and   PEER ENTITY AUTHENTICATION.Rescorla & Korver        Best Current Practice                  [Page 3]

RFC 3552           Security Considerations Guidelines          July 20032.1.1. Confidentiality   When most people think of security, they think of CONFIDENTIALITY.   Confidentiality means that your data is kept secret from unintended   listeners.  Usually, these listeners are simply eavesdroppers.  When   an adversary taps your phone, it poses a risk to your   confidentiality.   Obviously, if you have secrets, then you are probably concerned about   others discovering them.  Thus, at the very least, you want to   maintain confidentiality.  When you see spies in the movies go into   the bathroom and turn on all the water to foil bugging, the property   they're looking for is confidentiality.2.1.2. Data Integrity   The second primary goal is DATA INTEGRITY.  The basic idea here is   that we want to make sure that the data we receive is the same data   that the sender has sent.  In paper-based systems, some data   integrity comes automatically.  When you receive a letter written in   pen you can be fairly certain that no words have been removed by an   attacker because pen marks are difficult to remove from paper.   However, an attacker could have easily added some marks to the paper   and completely changed the meaning of the message.  Similarly, it's   easy to shorten the page to truncate the message.   On the other hand, in the electronic world, since all bits look   alike, it's trivial to tamper with messages in transit.  You simply   remove the message from the wire, copy out the parts you like, add   whatever data you want, and generate a new message of your choosing,   and the recipient is no wiser.  This is the moral equivalent of the   attacker taking a letter you wrote, buying some new paper and   recopying the message, changing it as he does it.  It's just a lot   easier to do electronically since all bits look alike.2.1.3. Peer Entity authentication   The third property we're concerned with is PEER ENTITY   AUTHENTICATION.  What we mean by this is that we know that one of the   endpoints in the communication is the one we intended.  Without peer   entity authentication, it's very difficult to provide either   confidentiality or data integrity.  For instance, if we receive a   message from Alice, the property of data integrity doesn't do us much   good unless we know that it was in fact sent by Alice and not the   attacker.  Similarly, if we want to send a confidential message to   Bob, it's not of much value to us if we're actually sending a   confidential message to the attacker.Rescorla & Korver        Best Current Practice                  [Page 4]

RFC 3552           Security Considerations Guidelines          July 2003   Note that peer entity authentication can be provided asymmetrically.   When you call someone on the phone, you can be fairly certain that   you have the right person -- or at least that you got a person who's   actually at the phone number you called.  On the other hand, if they   don't have caller ID, then the receiver of a phone call has no idea   who's calling them.  Calling someone on the phone is an example of   recipient authentication, since you know who the recipient of the   call is, but they don't know anything about the sender.   In messaging situations, you often wish to use peer entity   authentication to establish the identity of the sender of a certain   message.  In such contexts, this property is called DATA ORIGIN   AUTHENTICATION.2.2. Non-Repudiation   A system that provides endpoint authentication allows one party to be   certain of the identity of someone with whom he is communicating.   When the system provides data integrity a receiver can be sure of   both the sender's identity and that he is receiving the data that   that sender meant to send.  However, he cannot necessarily   demonstrate this fact to a third party.  The ability to make this   demonstration is called NON-REPUDIATION.   There are many situations in which non-repudiation is desirable.   Consider the situation in which two parties have signed a contract   which one party wishes to unilaterally abrogate.  He might simply   claim that he had never signed it in the first place.  Non-   repudiation prevents him from doing so, thus protecting the   counterparty.   Unfortunately, non-repudiation can be very difficult to achieve in   practice and naive approaches are generally inadequate.Section 4.3   describes some of the difficulties, which generally stem from the   fact that the interests of the two parties are not aligned -- one   party wishes to prove something that the other party wishes to deny.2.3. Systems Security   In general, systems security is concerned with protecting one's   machines and data.  The intent is that machines should be used only   by authorized users and for the purposes that the owners intend.   Furthermore, they should be available for those purposes.  Attackers   should not be able to deprive legitimate users of resources.Rescorla & Korver        Best Current Practice                  [Page 5]

RFC 3552           Security Considerations Guidelines          July 20032.3.1. Unauthorized Usage   Most systems are not intended to be completely accessible to the   public.  Rather, they are intended to be used only by certain   authorized individuals.  Although many Internet services are   available to all Internet users, even those servers generally offer a   larger subset of services to specific users.  For instance, Web   Servers often will serve data to any user, but restrict the ability   to modify pages to specific users.  Such modifications by the general   public would be UNAUTHORIZED USAGE.2.3.2. Inappropriate Usage   Being an authorized user does not mean that you have free run of the   system.  As we said above, some activities are restricted to   authorized users, some to specific users, and some activities are   generally forbidden to all but administrators.  Moreover, even   activities which are in general permitted might be forbidden in some   cases.  For instance, users may be permitted to send email but   forbidden from sending files above a certain size, or files which   contain viruses.  These are examples of INAPPROPRIATE USAGE.2.3.3. Denial of Service   Recall that our third goal was that the system should be available to   legitimate users.  A broad variety of attacks are possible which   threaten such usage.  Such attacks are collectively referred to as   DENIAL OF SERVICE attacks.  Denial of service attacks are often very   easy to mount and difficult to stop.  Many such attacks are designed   to consume machine resources, making it difficult or impossible to   serve legitimate users.  Other attacks cause the target machine to   crash, completely denying service to users.3. The Internet Threat Model   A THREAT MODEL describes the capabilities that an attacker is assumed   to be able to deploy against a resource.  It should contain such   information as the resources available to an attacker in terms of   information, computing capability, and control of the system.  The   purpose of a threat model is twofold.  First, we wish to identify the   threats we are concerned with.  Second, we wish to rule some threats   explicitly out of scope.  Nearly every security system is vulnerable   to a sufficiently dedicated and resourceful attacker.   The Internet environment has a fairly well understood threat model.   In general, we assume that the end-systems engaging in a protocol   exchange have not themselves been compromised.  Protecting against an   attack when one of the end-systems has been compromised isRescorla & Korver        Best Current Practice                  [Page 6]

RFC 3552           Security Considerations Guidelines          July 2003   extraordinarily difficult.  It is, however, possible to design   protocols which minimize the extent of the damage done under these   circumstances.   By contrast, we assume that the attacker has nearly complete control   of the communications channel over which the end-systems communicate.   This means that the attacker can read any PDU (Protocol Data Unit) on   the network and undetectably remove, change, or inject forged packets   onto the wire.  This includes being able to generate packets that   appear to be from a trusted machine.  Thus, even if the end-system   with which you wish to communicate is itself secure, the Internet   environment provides no assurance that packets which claim to be from   that system in fact are.   It's important to realize that the meaning of a PDU is different at   different levels.  At the IP level, a PDU means an IP packet.  At the   TCP level, it means a TCP segment.  At the application layer, it   means some kind of application PDU.  For instance, at the level of   email, it might either mean anRFC-822 message or a single SMTP   command.  At the HTTP level, it might mean a request or response.3.1. Limited Threat Models   As we've said, a resourceful and dedicated attacker can control the   entire communications channel.  However, a large number of attacks   can be mounted by an attacker with fewer resources.  A number of   currently known attacks can be mounted by an attacker with limited   control of the network.  For instance, password sniffing attacks can   be mounted by an attacker who can only read arbitrary packets.  This   is generally referred to as a PASSIVE ATTACK [INTAUTH].   By contrast, Morris' sequence number guessing attack [SEQNUM] can be   mounted by an attacker who can write but not read arbitrary packets.   Any attack which requires the attacker to write to the network is   known as an ACTIVE ATTACK.   Thus, a useful way of organizing attacks is to divide them based on   the capabilities required to mount the attack.  The rest of this   section describes these categories and provides some examples of each   category.3.2. Passive Attacks   In a passive attack, the attacker reads packets off the network but   does not write them.  The simplest way to mount such an attack is to   simply be on the same LAN as the victim.  On most common LAN   configurations, including Ethernet, 802.3, and FDDI, any machine on   the wire can read all traffic destined for any other machine on theRescorla & Korver        Best Current Practice                  [Page 7]

RFC 3552           Security Considerations Guidelines          July 2003   same LAN.  Note that switching hubs make this sort of sniffing   substantially more difficult, since traffic destined for a machine   only goes to the network segment which that machine is on.   Similarly, an attacker who has control of a host in the   communications path between two victim machines is able to mount a   passive attack on their communications.  It is also possible to   compromise the routing infrastructure to specifically arrange that   traffic passes through a compromised machine.  This might involve an   active attack on the routing infrastructure to facilitate a passive   attack on a victim machine.   Wireless communications channels deserve special consideration,   especially with the recent and growing popularity of wireless-based   LANs, such as those using 802.11.  Since the data is simply broadcast   on well known radio frequencies, an attacker simply needs to be able   to receive those transmissions.  Such channels are especially   vulnerable to passive attacks.  Although many such channels include   cryptographic protection, it is often of such poor quality as to be   nearly useless [WEP].   In general, the goal of a passive attack is to obtain information   which the sender and receiver would prefer to remain private.  This   private information may include credentials useful in the electronic   world and/or passwords or credentials useful in the outside world,   such as confidential business information.3.2.1. Confidentiality Violations   The classic example of passive attack is sniffing some inherently   private data off of the wire.  For instance, despite the wide   availability of SSL, many credit card transactions still traverse the   Internet in the clear.  An attacker could sniff such a message and   recover the credit card number, which can then be used to make   fraudulent transactions.  Moreover, confidential business information   is routinely transmitted over the network in the clear in email.3.2.2. Password Sniffing   Another example of a passive attack is PASSWORD SNIFFING.  Password   sniffing is directed towards obtaining unauthorized use of resources.   Many protocols, including [TELNET], [POP], and [NNTP] use a shared   password to authenticate the client to the server.  Frequently, this   password is transmitted from the client to the server in the clear   over the communications channel.  An attacker who can read this   traffic can therefore capture the password and REPLAY it.  In other   words, the attacker can initiate a connection to the server and pose   as the client and login using the captured password.Rescorla & Korver        Best Current Practice                  [Page 8]

RFC 3552           Security Considerations Guidelines          July 2003   Note that although the login phase of the attack is active, the   actual password capture phase is passive.  Moreover, unless the   server checks the originating address of connections, the login phase   does not require any special control of the network.3.2.3. Offline Cryptographic Attacks   Many cryptographic protocols are subject to OFFLINE ATTACKS.  In such   a protocol, the attacker recovers data which has been processed using   the victim's secret key and then mounts a cryptanalytic attack on   that key.  Passwords make a particularly vulnerable target because   they are typically low entropy.  A number of popular password-based   challenge response protocols are vulnerable to DICTIONARY ATTACK.   The attacker captures a challenge-response pair and then proceeds to   try entries from a list of common words (such as a dictionary file)   until he finds a password that produces the right response.   A similar such attack can be mounted on a local network when NIS is   used.  The Unix password is crypted using a one-way function, but   tools exist to break such crypted passwords [KLEIN].  When NIS is   used, the crypted password is transmitted over the local network and   an attacker can thus sniff the password and attack it.   Historically, it has also been possible to exploit small operating   system security holes to recover the password file using an active   attack.  These holes can then be bootstrapped into an actual account   by using the aforementioned offline password recovery techniques.   Thus we combine a low-level active attack with an offline passive   attack.3.3. Active Attacks   When an attack involves writing data to the network, we refer to this   as an ACTIVE ATTACK.  When IP is used without IPsec, there is no   authentication for the sender address.  As a consequence, it's   straightforward for an attacker to create a packet with a source   address of his choosing.  We'll refer to this as a SPOOFING ATTACK.   Under certain circumstances, such a packet may be screened out by the   network.  For instance, many packet filtering firewalls screen out   all packets with source addresses on the INTERNAL network that arrive   on the EXTERNAL interface.  Note, however, that this provides no   protection against an attacker who is inside the firewall.  In   general, designers should assume that attackers can forge packets.Rescorla & Korver        Best Current Practice                  [Page 9]

RFC 3552           Security Considerations Guidelines          July 2003   However, the ability to forge packets does not go hand in hand with   the ability to receive arbitrary packets.  In fact, there are active   attacks that involve being able to send forged packets but not   receive the responses.  We'll refer to these as BLIND ATTACKS.   Note that not all active attacks require forging addresses.  For   instance, the TCP SYN denial of service attack [TCPSYN] can be   mounted successfully without disguising the sender's address.   However, it is common practice to disguise one's address in order to   conceal one's identity if an attack is discovered.   Each protocol is susceptible to specific active attacks, but   experience shows that a number of common patterns of attack can be   adapted to any given protocol.  The next sections describe a number   of these patterns and give specific examples of them as applied to   known protocols.3.3.1. Replay Attacks   In a REPLAY ATTACK, the attacker records a sequence of messages off   of the wire and plays them back to the party which originally   received them.  Note that the attacker does not need to be able to   understand the messages.  He merely needs to capture and retransmit   them.   For example, consider the case where an S/MIME message is being used   to request some service, such as a credit card purchase or a stock   trade.  An attacker might wish to have the service executed twice, if   only to inconvenience the victim.  He could capture the message and   replay it, even though he can't read it, causing the transaction to   be executed twice.3.3.2. Message Insertion   In a MESSAGE INSERTION attack, the attacker forges a message with   some chosen set of properties and injects it into the network.  Often   this message will have a forged source address in order to disguise   the identity of the attacker.   For example, a denial-of-service attack can be mounted by inserting a   series of spurious TCP SYN packets directed towards the target host.   The target host responds with its own SYN and allocates kernel data   structures for the new connection.  The attacker never completes the   3-way handshake, so the allocated connection endpoints just sit there   taking up kernel memory.  Typical TCP stack implementations onlyRescorla & Korver        Best Current Practice                 [Page 10]

RFC 3552           Security Considerations Guidelines          July 2003   allow some limited number of connections in this "half-open" state   and when this limit is reached, no more connections can be initiated,   even from legitimate hosts.  Note that this attack is a blind attack,   since the attacker does not need to process the victim's SYNs.3.3.3. Message Deletion   In a MESSAGE DELETION attack, the attacker removes a message from the   wire.  Morris' sequence number guessing attack [SEQNUM] often   requires a message deletion attack to be performed successfully.  In   this blind attack, the host whose address is being forged will   receive a spurious TCP SYN packet from the host being attacked.   Receipt of this SYN packet generates a RST, which would tear the   illegitimate connection down.  In order to prevent this host from   sending a RST so that the attack can be carried out successfully,   Morris describes flooding this host to create queue overflows such   that the SYN packet is lost and thus never responded to.3.3.4. Message Modification   In a MESSAGE MODIFICATION attack, the attacker removes a message from   the wire, modifies it, and reinjects it into the network.  This sort   of attack is particularly useful if the attacker wants to send some   of the data in the message but also wants to change some of it.   Consider the case where the attacker wants to attack an order for   goods placed over the Internet.  He doesn't have the victim's credit   card number so he waits for the victim to place the order and then   replaces the delivery address (and possibly the goods description)   with his own.  Note that this particular attack is known as a CUT-   AND-PASTE attack since the attacker cuts the credit card number out   of the original message and pastes it into the new message.   Another interesting example of a cut-and-paste attack is provided by   [IPSPPROB].  If IPsec ESP is used without any MAC then it is possible   for the attacker to read traffic encrypted for a victim on the same   machine.  The attacker attaches an IP header corresponding to a port   he controls onto the encrypted IP packet.  When the packet is   received by the host it will automatically be decrypted and forwarded   to the attacker's port.  Similar techniques can be used to mount a   session hijacking attack.  Both of these attacks can be avoided by   always using message authentication when you use encryption.  Note   that this attack only works if (1) no MAC check is being used, since   this attack generates damaged packets (2) a host-to-host SA is being   used, since a user-to-user SA will result in an inconsistency between   the port associated with the SA and the target port.  If the   receiving machine is single-user than this attack is infeasible.Rescorla & Korver        Best Current Practice                 [Page 11]

RFC 3552           Security Considerations Guidelines          July 20033.3.5. Man-In-The-Middle   A MAN-IN-THE-MIDDLE attack combines the above techniques in a special   form: The attacker subverts the communication stream in order to pose   as the sender to receiver and the receiver to the sender:      What Alice and Bob think:      Alice  <---------------------------------------------->  Bob      What's happening:      Alice  <---------------->  Attacker  <---------------->  Bob   This differs fundamentally from the above forms of attack because it   attacks the identity of the communicating parties, rather than the   data stream itself.  Consequently, many techniques which provide   integrity of the communications stream are insufficient to protect   against man-in-the-middle attacks.   Man-in-the-middle attacks are possible whenever a protocol lacks PEER   ENTITY AUTHENTICATION.  For instance, if an attacker can hijack the   client TCP connection during the TCP handshake (perhaps by responding   to the client's SYN before the server does), then the attacker can   open another connection to the server and begin a man-in-the-middle   attack.  It is also trivial to mount man-in-the-middle attacks on   local networks via ARP spoofing -- the attacker forges an ARP with   the victim's IP address and his own MAC address.  Tools to mount this   sort of attack are readily available.   Note that it is only necessary to authenticate one side of the   transaction in order to prevent man-in-the-middle attacks.  In such a   situation the the peers can establish an association in which only   one peer is authenticated.  In such a system, an attacker can   initiate an association posing as the unauthenticated peer but cannot   transmit or access data being sent on a legitimate connection.  This   is an acceptable situation in contexts such as Web e-commerce where   only the server needs to be authenticated (or the client is   independently authenticated via some non-cryptographic mechanism such   as a credit card number).3.4. Topological Issues   In practice, the assumption that it's equally easy for an attacker to   read and generate all packets is false, since the Internet is not   fully connected.  This has two primary implications.Rescorla & Korver        Best Current Practice                 [Page 12]

RFC 3552           Security Considerations Guidelines          July 20033.5. On-path versus off-path   In order for a datagram to be transmitted from one host to another,   it generally must traverse some set of intermediate links and   gateways.  Such gateways are naturally able to read, modify, or   remove any datagram transmitted along that path.  This makes it much   easier to mount a wide variety of attacks if you are on-path.   Off-path hosts can, of course, transmit arbitrary datagrams that   appear to come from any hosts but cannot necessarily receive   datagrams intended for other hosts.  Thus, if an attack depends on   being able to receive data, off-path hosts must first subvert the   topology in order to place themselves on-path.  This is by no means   impossible but is not necessarily trivial.   Applications protocol designers MUST NOT assume that all attackers   will be off-path.  Where possible, protocols SHOULD be designed to   resist attacks from attackers who have complete control of the   network.  However, designers are expected to give more weight to   attacks which can be mounted by off-path attackers as well as on-path   ones.3.6. Link-local   One specialized case of on-path is being on the same link.  In some   situations, it's desirable to distinguish between hosts who are on   the local network and those who are not.  The standard technique for   this is verifying the IP TTL value [IP].  Since the TTL must be   decremented by each forwarder, a protocol can demand that TTL be set   to 255 and that all receivers verify the TTL.  A receiver then has   some reason to believe that conforming packets are from the same   link.  Note that this technique must be used with care in the   presence of tunneling systems, since such systems may pass packets   without decrementing TTL.4. Common Issues   Although each system's security requirements are unique, certain   common requirements appear in a number of protocols.  Often, when   naive protocol designers are faced with these requirements, they   choose an obvious but insecure solution even though better solutions   are available.  This section describes a number of issues seen in   many protocols and the common pieces of security technology that may   be useful in addressing them.Rescorla & Korver        Best Current Practice                 [Page 13]

RFC 3552           Security Considerations Guidelines          July 20034.1. User Authentication   Essentially every system which wants to control access to its   resources needs some way to authenticate users.  A nearly uncountable   number of such mechanisms have been designed for this purpose.  The   next several sections describe some of these techniques.4.1.1. Username/Password   The most common access control mechanism is simple USERNAME/PASSWORD   The user provides a username and a reusable password to the host   which he wishes to use.  This system is vulnerable to a simple   passive attack where the attacker sniffs the password off the wire   and then initiates a new session, presenting the password.  This   threat can be mitigated by hosting the protocol over an encrypted   connection such as TLS or IPSEC.  Unprotected (plaintext)   username/password systems are not acceptable in IETF standards.4.1.2. Challenge Response and One Time Passwords   Systems which desire greater security than USERNAME/PASSWORD often   employ either a ONE TIME PASSWORD [OTP] scheme or a CHALLENGE-   RESPONSE.  In a one time password scheme, the user is provided with a   list of passwords, which must be used in sequence, one time each.   (Often these passwords are generated from some secret key so the user   can simply compute the next password in the sequence.)  SecureID and   DES Gold are variants of this scheme.  In a challenge-response   scheme, the host and the user share some secret (which often is   represented as a password).  In order to authenticate the user, the   host presents the user with a (randomly generated) challenge.  The   user computes some function based on the challenge and the secret and   provides that to the host, which verifies it.  Often this computation   is performed in a handheld device, such as a DES Gold card.   Both types of scheme provide protection against replay attack, but   often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of   passive attack): As previously mentioned, often the one-time password   or response is computed from a shared secret.  If the attacker knows   the function being used, he can simply try all possible shared   secrets until he finds one that produces the right output.  This is   made easier if the shared secret is a password, in which case he can   mount a DICTIONARY ATTACK -- meaning that he tries a list of common   words (or strings) rather than just random strings.   These systems are also often vulnerable to an active attack.  Unless   communication security is provided for the entire session, the   attacker can simply wait until authentication has been performed and   hijack the connection.Rescorla & Korver        Best Current Practice                 [Page 14]

RFC 3552           Security Considerations Guidelines          July 20034.1.3. Shared Keys   CHALLENGE-RESPONSE type systems can be made secure against dictionary   attack by using randomly generated shared keys instead of user-   generated passwords.  If the keys are sufficiently large then   keysearch attacks become impractical.  This approach works best when   the keys are configured into the end nodes rather than memorized and   typed in by users, since users have trouble remembering sufficiently   long keys.   Like password-based systems, shared key systems suffer from   management problems.  Each pair of communicating parties must have   their own agreed-upon key, which leads to there being a lot of keys.4.1.4. Key Distribution Centers   One approach to solving the large number of keys problem is to use an   online "trusted third party" that mediates between the authenticating   parties.  The trusted third party (generally called a a KEY   DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with   each party in the system.  It first contacts the KDC which gives it a   TICKET containing a randomly generated symmetric key encrypted under   both peer's keys.  Since only the proper peers can decrypt the   symmetric key the ticket can be used to establish a trusted   association.  By far the most popular KDC system is Kerberos   [KERBEROS].4.1.5. Certificates   A simple approach is to have all users have CERTIFICATES [PKIX] which   they then use to authenticate in some protocol-specific way, as in   [TLS] or [S/MIME].  A certificate is a signed credential binding an   entity's identity to its public key.  The signer of a certificate is   a CERTIFICATE AUTHORITY (CA), whose certificate may itself be signed   by some superior CA.  In order for this system to work, trust in one   or more CAs must be established in an out-of-band fashion.  Such CAs   are referred to as TRUSTED ROOTS or ROOT CAS.  The primary obstacle   to this approach in client-server type systems is that it requires   clients to have certificates, which can be a deployment problem.4.1.6. Some Uncommon Systems   There are ways to do a better job than the schemes mentioned above,   but they typically don't add much security unless communications   security (at least message integrity) will be employed to secure the   connection, because otherwise the attacker can merely hijack the   connection after authentication has been performed.  A number of   protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap aRescorla & Korver        Best Current Practice                 [Page 15]

RFC 3552           Security Considerations Guidelines          July 2003   user's password into a shared key which can be used as input to a   cryptographic protocol.  One major obstacle to the deployment of   these protocols has been that their Intellectual Property status is   extremely unclear.  Similarly, the user can authenticate using public   key certificates (e.g., S-HTTP client authentication).  Typically   these methods are used as part of a more complete security protocol.4.1.7. Host Authentication   Host authentication presents a special problem.  Quite commonly, the   addresses of services are presented using a DNS hostname, for   instance as a URL [URL].  When requesting such a service, one has to   ensure that the entity that one is talking to not only has a   certificate but that that certificate corresponds to the expected   identity of the server.  The important thing to have is a secure   binding between the certificate and the expected hostname.   For instance, it is usually not acceptable for the certificate to   contain an identity in the form of an IP address if the request was   for a given hostname.  This does not provide end-to-end security   because the hostname-IP mapping is not secure unless secure name   resolution [DNSSEC] is being used.  This is a particular problem when   the hostname is presented at the application layer but the   authentication is performed at some lower layer.4.2. Generic Security Frameworks   Providing security functionality in a protocol can be difficult.  In   addition to the problem of choosing authentication and key   establishment mechanisms, one needs to integrate it into a protocol.   One response to this problem (embodied in IPsec and TLS) is to create   a lower-level security protocol and then insist that new protocols be   run over that protocol.  Another approach that has recently become   popular is to design generic application layer security frameworks.   The idea is that you design a protocol that allows you to negotiate   various security mechanisms in a pluggable fashion.  Application   protocol designers then arrange to carry the security protocol PDUs   in their application protocol.  Examples of such frameworks include   GSS-API [GSS] and SASL [SASL].   The generic framework approach has a number of problems.  First, it   is highly susceptible to DOWNGRADE ATTACKS.  In a downgrade attack,   an active attacker tampers with the negotiation in order to force the   parties to negotiate weaker protection than they otherwise would.   It's possible to include an integrity check after the negotiation and   key establishment have both completed, but the strength of this   integrity check is necessarily limited to the weakest common   algorithm.  This problem exists with any negotiation approach, butRescorla & Korver        Best Current Practice                 [Page 16]

RFC 3552           Security Considerations Guidelines          July 2003   generic frameworks exacerbate it by encouraging the application   protocol author to just specify the framework rather than think hard   about the appropriate underlying mechanisms, particularly since the   mechanisms can very widely in the degree of security offered.   Another problem is that it's not always obvious how the various   security features in the framework interact with the application   layer protocol.  For instance, SASL can be used merely as an   authentication framework -- in which case the SASL exchange occurs   but the rest of the connection is unprotected, but can also negotiate   traffic protection, such as via GSS, as a mechanism.  Knowing under   what circumstances traffic protection is optional and which it is   required requires thinking about the threat model.   In general, authentication frameworks are most useful in situations   where new protocols are being added to systems with pre-existing   legacy authentication systems.  A framework allows new installations   to provide better authentication while not forcing existing sites   completely redo their legacy authentication systems.  When the   security requirements of a system can be clearly identified and only   a few forms of authentication are used, choosing a single security   mechanism leads to greater simplicity and predictability.  In   situations where a framework is to be used, designers SHOULD   carefully examine the framework's options and specify only the   mechanisms that are appropriate for their particular threat model.   If a framework is necessary, designers SHOULD choose one of the   established ones instead of designing their own.4.3. Non-repudiation   The naive approach to non-repudiation is simply to use public-key   digital signatures over the content.  The party who wishes to be   bound (the SIGNING PARTY) digitally signs the message in question.   The counterparty (the RELYING PARTY) can later point to the digital   signature as proof that the signing party at one point agreed to the   disputed message.  Unfortunately, this approach is insufficient.   The easiest way for the signing party to repudiate the message is by   claiming that his private key has been compromised and that some   attacker (though not necessarily the relying party) signed the   disputed message.  In order to defend against this attack the relying   party needs to demonstrate that the signing party's key had not been   compromised at the time of the signature.  This requires substantial   infrastructure, including archival storage of certificate revocation   information and timestamp servers to establish the time that the   message was signed.Rescorla & Korver        Best Current Practice                 [Page 17]

RFC 3552           Security Considerations Guidelines          July 2003   Additionally, the relying party might attempt to trick the signing   party into signing one message while thinking he's signing another.   This problem is particularly severe when the relying party controls   the infrastructure that the signing party uses for signing, such as   in kiosk situations.  In many such situations the signing party's key   is kept on a smartcard but the message to be signed is displayed by   the relying party.   All of these complications make non-repudiation a difficult service   to deploy in practice.4.4. Authorization vs. Authentication   AUTHORIZATION is the process by which one determines whether an   authenticated party has permission to access a particular resource or   service.  Although tightly bound, it is important to realize that   authentication and authorization are two separate mechanisms.   Perhaps because of this tight coupling, authentication is sometimes   mistakenly thought to imply authorization.  Authentication simply   identifies a party, authorization defines whether they can perform a   certain action.   Authorization necessarily relies on authentication, but   authentication alone does not imply authorization.  Rather, before   granting permission to perform an action, the authorization mechanism   must be consulted to determine whether that action is permitted.4.4.1. Access Control Lists   One common form of authorization mechanism is an access control list   (ACL), which lists users that are permitted access to a resource.   Since assigning individual authorization permissions to each resource   is tedious, resources are often hierarchically arranged so that the   parent resource's ACL is inherited by child resources.  This allows   administrators to set top level policies and override them when   necessary.4.4.2. Certificate Based Systems   While the distinction between authentication and authorization is   intuitive when using simple authentication mechanisms such as   username and password (i.e., everyone understands the difference   between the administrator account and a user account), with more   complex authentication mechanisms the distinction is sometimes lost.   With certificates, for instance, presenting a valid signature does   not imply authorization.  The signature must be backed by a   certificate chain that contains a trusted root, and that root must beRescorla & Korver        Best Current Practice                 [Page 18]

RFC 3552           Security Considerations Guidelines          July 2003   trusted in the given context.  For instance, users who possess   certificates issued by the Acme MIS CA may have different web access   privileges than users who possess certificates issued by the Acme   Accounting CA, even though both of these CAs are "trusted" by the   Acme web server.   Mechanisms for enforcing these more complicated properties have not   yet been completely explored.  One approach is simply to attach   policies to ACLs describing what sorts of certificates are trusted.   Another approach is to carry that information with the certificate,   either as a certificate extension/attribute [PKIX,SPKI] or as a   separate "Attribute Certificate".4.5. Providing Traffic Security   Securely designed protocols should provide some mechanism for   securing (meaning integrity protecting, authenticating, and possibly   encrypting) all sensitive traffic.  One approach is to secure the   protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP].  Although this   provides security which is most fitted to the protocol, it also   requires considerable effort to get right.   Many protocols can be adequately secured using one of the available   channel security systems.  We'll discuss the two most common, IPsec   [AH,ESP] and [TLS].4.5.1. IPsec   The IPsec protocols (specifically, AH and ESP) can provide   transmission security for all traffic between two hosts.  The IPsec   protocols support varying granularities of user identification,   including for example "IP Subnet", "IP Address", "Fully Qualified   Domain Name", and individual user ("Mailbox name").  These varying   levels of identification are employed as inputs to access control   facilities that are an intrinsic part of IPsec.  However, a given   IPsec implementation might not support all identity types.  In   particular, security gateways may not provide user-to-user   authentication or have mechanisms to provide that authentication   information to applications.   When AH or ESP is used, the application programmer might not need to   do anything (if AH or ESP has been enabled system-wide) or might need   to make specific software changes (e.g., adding specific setsockopt()   calls) -- depending on the AH or ESP implementation being used.   Unfortunately, APIs for controlling IPsec implementations are not yet   standardized.Rescorla & Korver        Best Current Practice                 [Page 19]

RFC 3552           Security Considerations Guidelines          July 2003   The primary obstacle to using IPsec to secure other protocols is   deployment.  The major use of IPsec at present is for VPN   applications, especially for remote network access.  Without   extremely tight coordination between security administrators and   application developers, VPN usage is not well suited to providing   security services for individual applications since it is difficult   for such applications to determine what security services have in   fact been provided.   IPsec deployment in host-to-host environments has been slow.  Unlike   application security systems such as TLS, adding IPsec to a non-IPsec   system generally involves changing the operating system, either by   modifying with the kernel or installing new drivers.  This is a   substantially greater undertaking than simply installing a new   application.  However, recent versions of a number of commodity   operating systems include IPsec stacks, so deployment is becoming   easier.   In environments where IPsec is sure to be available, it represents a   viable option for protecting application communications traffic.  If   the traffic to be protected is UDP, IPsec and application-specific   object security are the only options.  However, designers MUST NOT   assume that IPsec will be available.  A security policy for a generic   application layer protocol SHOULD NOT simply state that IPsec must be   used, unless there is some reason to believe that IPsec will be   available in the intended deployment environment.  In environments   where IPsec may not be available and the traffic is solely TCP, TLS   is the method of choice, since the application developer can easily   ensure its presence by including a TLS implementation in his package.   In the special-case of IPv6, both AH and ESP are mandatory to   implement.  Hence, it is reasonable to assume that AH/ESP are already   available for IPv6-only protocols or IPv6-only deployments.  However,   automatic key management (IKE) is not required to implement so   protocol designers SHOULD not assume it will be present.  [USEIPSEC]   provides quite a bit of guidance on when IPsec is a good choice.4.5.2. SSL/TLS   Currently, the most common approach is to use SSL or its successor   TLS.  They provide channel security for a TCP connection at the   application level.  That is, they run over TCP.  SSL implementations   typically provide a Berkeley Sockets-like interface for easy   programming.  The primary issue when designing a protocol solution   around TLS is to differentiate between connections protected using   TLS and those which are not.Rescorla & Korver        Best Current Practice                 [Page 20]

RFC 3552           Security Considerations Guidelines          July 2003   The two primary approaches used have a separate well-known port for   TLS connections (e.g., the HTTP over TLS port is 443) [HTTPTLS] or to   have a mechanism for negotiating upward from the base protocol to TLS   as in [UPGRADE] or [STARTTLS].  When an upward negotiation strategy   is used, care must be taken to ensure that an attacker can not force   a clear connection when both parties wish to use TLS.   Note that TLS depends upon a reliable protocol such as TCP or SCTP.   This produces two notable difficulties.  First, it cannot be used to   secure datagram protocols that use UDP.  Second, TLS is susceptible   to IP layer attacks that IPsec is not.  Typically, these attacks take   some form of denial of service or connection assassination.  For   instance, an attacker might forge a TCP RST to shut down SSL   connections.  TLS has mechanisms to detect truncation attacks but   these merely allow the victim to know he is being attacked and do not   provide connection survivability in the face of such attacks.  By   contrast, if IPsec were being used, such a forged RST could be   rejected without affecting the TCP connection.  If forged RSTs or   other such attacks on the TCP connection are a concern, then AH/ESP   or the TCP MD5 option [TCPMD5] are the preferred choices.4.5.2.1. Virtual Hosts   If the "separate ports" approach to TLS is used, then TLS will be   negotiated before any application-layer traffic is sent.  This can   cause a problem with protocols that use virtual hosts, such as   [HTTP], since the server does not know which certificate to offer the   client during the TLS handshake.  The TLS hostname extension [TLSEXT]   can be used to solve this problem, although it is too new to have   seen wide deployment.4.5.2.2. Remote Authentication and TLS   One difficulty with using TLS is that the server is authenticated via   a certificate.  This can be inconvenient in environments where   previously the only form of authentication was a password shared   between client and server.  It's tempting to use TLS without an   authenticated server (i.e., with anonymous DH or a self-signed RSA   certificate) and then authenticate via some challenge-response   mechanism such as SASL with CRAM-MD5.   Unfortunately, this composition of SASL and TLS is less strong than   one would expect.  It's easy for an active attacker to hijack this   connection.  The client man-in-the-middles the SSL connection   (remember we're not authenticating the server, which is what   ordinarily prevents this attack) and then simply proxies the SASL   handshake.  From then on, it's as if the connection were in theRescorla & Korver        Best Current Practice                 [Page 21]

RFC 3552           Security Considerations Guidelines          July 2003   clear, at least as far as that attacker is concerned.  In order to   prevent this attack, the client needs to verify the server's   certificate.   However, if the server is authenticated, challenge-response becomes   less desirable.  If you already have a hardened channel then simple   passwords are fine.  In fact, they're arguably superior to   challenge-response since they do not require that the password be   stored in the clear on the server.  Thus, compromise of the key file   with challenge-response systems is more serious than if simple   passwords were used.   Note that if the client has a certificate than SSL-based client   authentication can be used.  To make this easier, SASL provides the   EXTERNAL mechanism, whereby the SASL client can tell the server   "examine the outer channel for my identity".  Obviously, this is not   subject to the layering attacks described above.4.5.3. Remote Login   In some special cases it may be worth providing channel-level   security directly in the application rather than using IPSEC or   SSL/TLS.  One such case is remote terminal security.  Characters are   typically delivered from client to server one character at a time.   Since SSL/TLS and AH/ESP authenticate and encrypt every packet, this   can mean a data expansion of 20-fold.  The telnet encryption option   [ENCOPT] prevents this expansion by foregoing message integrity.   When using remote terminal service, it's often desirable to securely   perform other sorts of communications services.  In addition to   providing remote login, SSH [SSH] also provides secure port   forwarding for arbitrary TCP ports, thus allowing users run arbitrary   TCP-based applications over the SSH channel.  Note that SSH Port   Forwarding can be security issue if it is used improperly to   circumvent firewall and improperly expose insecure internal   applications to the outside world.4.6. Denial of Service Attacks and Countermeasures   Denial of service attacks are all too frequently viewed as an fact of   life.  One problem is that an attacker can often choose from one of   many denial of service attacks to inflict upon a victim, and because   most of these attacks cannot be thwarted, common wisdom frequently   assumes that there is no point protecting against one kind of denial   of service attack when there are many other denial of service attacks   that are possible but that cannot be prevented.Rescorla & Korver        Best Current Practice                 [Page 22]

RFC 3552           Security Considerations Guidelines          July 2003   However, not all denial of service attacks are equal and more   importantly, it is possible to design protocols so that denial of   service attacks are made more difficult, if not impractical.  Recent   SYN flood attacks [TCPSYN] demonstrate both of these properties: SYN   flood attacks are so easy, anonymous, and effective that they are   more attractive to attackers than other attacks; and because the   design of TCP enables this attack.   Because complete DoS protection is so difficult, security against DoS   must be dealt with pragmatically.  In particular, some attacks which   would be desirable to defend against cannot be defended against   economically.  The goal should be to manage risk by defending against   attacks with sufficiently high ratios of severity to cost of defense.   Both severity of attack and cost of defense change as technology   changes and therefore so does the set of attacks which should be   defended against.   Authors of internet standards MUST describe which denial of service   attacks their protocol is susceptible to.  This description MUST   include the reasons it was either unreasonable or out of scope to   attempt to avoid these denial of service attacks.4.6.1. Blind Denial of Service   BLIND denial of service attacks are particularly pernicious.  With a   blind attack the attacker has a significant advantage.  If the   attacker must be able to receive traffic from the victim, then he   must either subvert the routing fabric or use his own IP address.   Either provides an opportunity for the victim to track the attacker   and/or filter out his traffic.  With a blind attack the attacker can   use forged IP addresses, making it extremely difficult for the victim   to filter out his packets.  The TCP SYN flood attack is an example of   a blind attack.  Designers should make every attempt possible to   prevent blind denial of service attacks.4.6.2. Distributed Denial of Service   Even more dangerous are DISTRIBUTED denial of service attacks (DDoS)   [DDOS].  In a DDoS the attacker arranges for a number of machines to   attack the target machine simultaneously.  Usually this is   accomplished by infecting a large number of machines with a program   that allows remote initiation of attacks.  The machines actually   performing the attack are called ZOMBIEs and are likely owned by   unsuspecting third parties in an entirely different location from the   true attacker.  DDoS attacks can be very hard to counter because the   zombies often appear to be making legitimate protocol requests andRescorla & Korver        Best Current Practice                 [Page 23]

RFC 3552           Security Considerations Guidelines          July 2003   simply crowd out the real users.  DDoS attacks can be difficult to   thwart, but protocol designers are expected to be cognizant of these   forms of attack while designing protocols.4.6.3. Avoiding Denial of Service   There are two common approaches to making denial of service attacks   more difficult:4.6.3.1. Make your attacker do more work than you do   If an attacker consumes more of his resources than yours when   launching an attack, attackers with fewer resources than you will be   unable to launch effective attacks.  One common technique is to   require the attacker perform a time-intensive operation, such as a   cryptographic operation.  Note that an attacker can still mount a   denial of service attack if he can muster substantially sufficient   CPU power.  For instance, this technique would not stop the   distributed attacks described in [TCPSYN].4.6.3.2. Make your attacker prove they can receive data from you   A blind attack can be subverted by forcing the attacker to prove that   they can can receive data from the victim.  A common technique is to   require that the attacker reply using information that was gained   earlier in the message exchange.  If this countermeasure is used, the   attacker must either use his own address (making him easy to track)   or to forge an address which will be routed back along a path that   traverses the host from which the attack is being launched.   Hosts on small subnets are thus useless to the attacker (at least in   the context of a spoofing attack) because the attack can be traced   back to a subnet (which should be sufficient for locating the   attacker) so that anti-attack measures can be put into place (for   instance, a boundary router can be configured to drop all traffic   from that subnet).  A common technique is to require that the   attacker reply using information that was gained earlier in the   message exchange.4.6.4. Example: TCP SYN Floods   TCP/IP is vulnerable to SYN flood attacks (which are described insection 3.3.2) because of the design of the 3-way handshake.  First,   an attacker can force a victim to consume significant resources (in   this case, memory) by sending a single packet.  Second, because the   attacker can perform this action without ever having received data   from the victim, the attack can be performed anonymously (and   therefore using a large number of forged source addresses).Rescorla & Korver        Best Current Practice                 [Page 24]

RFC 3552           Security Considerations Guidelines          July 20034.6.5. Example: Photuris   [PHOTURIS] specifies an anti-clogging mechanism that prevents attacks   on Photuris that resemble the SYN flood attack.  Photuris employs a   time-variant secret to generate a "cookie" which is returned to the   attacker.  This cookie must be returned in subsequent messages for   the exchange to progress.  The interesting feature is that this   cookie can be regenerated by the victim later in the exchange, and   thus no state need be retained by the victim until after the attacker   has proven that he can receive packets from the victim.4.7. Object vs. Channel Security   It's useful to make the conceptual distinction between object   security and channel security.  Object security refers to security   measures which apply to entire data objects.  Channel security   measures provide a secure channel over which objects may be carried   transparently but the channel has no special knowledge about object   boundaries.   Consider the case of an email message.  When it's carried over an   IPSEC or TLS secured connection, the message is protected during   transmission.  However, it is unprotected in the receiver's mailbox,   and in intermediate spool files along the way.  Moreover, since mail   servers generally run as a daemon, not a user, authentication of   messages generally merely means authentication of the daemon not the   user.  Finally, since mail transport is hop-by-hop, even if the user   authenticates to the first hop relay the authentication can't be   safely verified by the receiver.   By contrast, when an email message is protected with S/MIME or   OpenPGP, the entire message is encrypted and integrity protected   until it is examined and decrypted by the recipient.  It also   provides strong authentication of the actual sender, as opposed to   the machine the message came from.  This is object security.   Moreover, the receiver can prove the signed message's authenticity to   a third party.   Note that the difference between object and channel security is a   matter of perspective.  Object security at one layer of the protocol   stack often looks like channel security at the next layer up.  So,   from the perspective of the IP layer, each packet looks like an   individually secured object.  But from the perspective of a web   client, IPSEC just provides a secure channel.   The distinction isn't always clear-cut.  For example, S-HTTP provides   object level security for a single HTTP transaction, but a web page   typically consists of multiple HTTP transactions (the base page andRescorla & Korver        Best Current Practice                 [Page 25]

RFC 3552           Security Considerations Guidelines          July 2003   numerous inline images).  Thus, from the perspective of the total web   page, this looks rather more like channel security.  Object security   for a web page would consist of security for the transitive closure   of the page and all its embedded content as a single unit.4.8. Firewalls and Network Topology   It's common security practice in modern networks to partition the   network into external and internal networks using a firewall.  The   internal network is then assumed to be secure and only limited   security measures are used there.  The internal portion of such a   network is often called a WALLED GARDEN.   Internet protocol designers cannot safely assume that their protocols   will be deployed in such an environment, for three reasons.  First,   protocols which were originally designed to be deployed in closed   environments often are later deployed on the Internet, thus creating   serious vulnerabilities.   Second, networks which appear to be topologically disconnected may   not be.  One reason may be that the network has been reconfigured to   allow access by the outside world.  Moreover, firewalls are   increasingly passing generic application layer protocols such as   [SOAP] or [HTTP].  Network protocols which are based on these generic   protocols cannot in general assume that a firewall will protect them.   Finally, one of the most serious security threats to systems is from   insiders, not outsiders.  Since insiders by definition have access to   the internal network, topological protections such as firewalls will   not protect them.5. Writing Security Considerations Sections   While it is not a requirement that any given protocol or system be   immune to all forms of attack, it is still necessary for authors to   consider as many forms as possible.  Part of the purpose of the   Security Considerations section is to explain what attacks are out of   scope and what countermeasures can be applied to defend against them.   In   There should be a clear description of the kinds of threats on the   described protocol or technology.  This should be approached as an   effort to perform "due diligence" in describing all known or   foreseeable risks and threats to potential implementers and users.Rescorla & Korver        Best Current Practice                 [Page 26]

RFC 3552           Security Considerations Guidelines          July 2003   Authors MUST describe      1.   which attacks are out of scope (and why!)      2.   which attacks are in-scope      2.1  and the protocol is susceptible to      2.2  and the protocol protects against   At least the following forms of attack MUST be considered:   eavesdropping, replay, message insertion, deletion, modification, and   man-in-the-middle.  Potential denial of service attacks MUST be   identified as well.  If the protocol incorporates cryptographic   protection mechanisms, it should be clearly indicated which portions   of the data are protected and what the protections are (i.e.,   integrity only, confidentiality, and/or endpoint authentication,   etc.).  Some indication should also be given to what sorts of attacks   the cryptographic protection is susceptible.  Data which should be   held secret (keying material, random seeds, etc.) should be clearly   labeled.   If the technology involves authentication, particularly user-host   authentication, the security of the authentication method MUST be   clearly specified.  That is, authors MUST document the assumptions   that the security of this authentication method is predicated upon.   For instance, in the case of the UNIX username/password login method,   a statement to the effect of:      Authentication in the system is secure only to the extent that it      is difficult to guess or obtain a ASCII password that is a maximum      of 8 characters long.  These passwords can be obtained by sniffing      telnet sessions or by running the 'crack' program using the      contents of the /etc/passwd file.  Attempts to protect against      on-line password guessing by (1) disconnecting after several      unsuccessful login attempts and (2) waiting between successive      password prompts is effective only to the extent that attackers      are impatient.      Because the /etc/passwd file maps usernames to user ids, groups,      etc. it must be world readable.  In order to permit this usage but      make running crack more difficult, the file is often split into      /etc/passwd and a 'shadow' password file.  The shadow file is not      world readable and contains the encrypted password.  The regular      /etc/passwd file contains a dummy password in its place.   It is insufficient to simply state that one's protocol should be run   over some lower layer security protocol.  If a system relies upon   lower layer security services for security, the protections thoseRescorla & Korver        Best Current Practice                 [Page 27]

RFC 3552           Security Considerations Guidelines          July 2003   services are expected to provide MUST be clearly specified.  In   addition, the resultant properties of the combined system need to be   specified.   Note: In general, the IESG will not approve standards track protocols   which do not provide for strong authentication, either internal to   the protocol or through tight binding to a lower layer security   protocol.   The threat environment addressed by the Security Considerations   section MUST at a minimum include deployment across the global   Internet across multiple administrative boundaries without assuming   that firewalls are in place, even if only to provide justification   for why such consideration is out of scope for the protocol.  It is   not acceptable to only discuss threats applicable to LANs and ignore   the broader threat environment.  All IETF standards-track protocols   are considered likely to have deployment in the global Internet.  In   some cases, there might be an Applicability Statement discouraging   use of a technology or protocol in a particular environment.   Nonetheless, the security issues of broader deployment should be   discussed in the document.   There should be a clear description of the residual risk to the user   or operator of that protocol after threat mitigation has been   deployed.  Such risks might arise from compromise in a related   protocol (e.g., IPsec is useless if key management has been   compromised), from incorrect implementation, compromise of the   security technology used for risk reduction (e.g., a cipher with a   40-bit key), or there might be risks that are not addressed by the   protocol specification (e.g., denial of service attacks on an   underlying link protocol).  Particular care should be taken in   situations where the compromise of a single system would compromise   an entire protocol.  For instance, in general protocol designers   assume that end-systems are inviolate and don't worry about physical   attack.  However, in cases (such as a certificate authority) where   compromise of a single system could lead to widespread compromises,   it is appropriate to consider systems and physical security as well.   There should also be some discussion of potential security risks   arising from potential misapplications of the protocol or technology   described in the RFC.  This might be coupled with an Applicability   Statement for that RFC.6. Examples   This section consists of some example security considerations   sections, intended to give the reader a flavor of what's intended by   this document.Rescorla & Korver        Best Current Practice                 [Page 28]

RFC 3552           Security Considerations Guidelines          July 2003   The first example is a 'retrospective' example, applying the criteria   of this document to an existing widely deployed protocol, SMTP.  The   second example is a good security considerations section clipped from   a current protocol.6.1. SMTP   WhenRFC 821 was written, Security Considerations sections were not   required in RFCs, and none is contained in that document.  [RFC 2821]   updatedRFC 821 and added a detailed security considerations section.   We reproduce here the Security Considerations section from that   document (with new section numbers).  Our comments are indented and   prefaced with 'NOTE:'.  We also add a number of new sections to cover   topics we consider important.  Those sections are marked with [NEW]   in the section header.6.1.1. Security Considerations6.1.1.1. Mail Security and Spoofing   SMTP mail is inherently insecure in that it is feasible for even   fairly casual users to negotiate directly with receiving and relaying   SMTP servers and create messages that will trick a naive recipient   into believing that they came from somewhere else.  Constructing such   a message so that the "spoofed" behavior cannot be detected by an   expert is somewhat more difficult, but not sufficiently so as to be a   deterrent to someone who is determined and knowledgeable.   Consequently, as knowledge of Internet mail increases, so does the   knowledge that SMTP mail inherently cannot be authenticated, or   integrity checks provided, at the transport level.  Real mail   security lies only in end-to-end methods involving the message   bodies, such as those which use digital signatures (see [14] and,   e.g., PGP [4] or S/MIME [31]).      NOTE: One bad approach to sender authentication is [IDENT] in      which the receiving mail server contacts the alleged sender and      asks for the username of the sender.  This is a bad idea for a      number of reasons, including but not limited to relaying, TCP      connection hijacking, and simple lying by the origin server.      Aside from the fact that IDENT is of low security value, use of      IDENT by receiving sites can lead to operational problems.  Many      sending sites blackhole IDENT requests, thus causing mail to be      held until the receiving server's IDENT request times out.   Various protocol extensions and configuration options that provide   authentication at the transport level (e.g., from an SMTP client to   an SMTP server) improve somewhat on the traditional situation   described above.  However, unless they are accompanied by carefulRescorla & Korver        Best Current Practice                 [Page 29]

RFC 3552           Security Considerations Guidelines          July 2003   handoffs of responsibility in a carefully-designed trust environment,   they remain inherently weaker than end-to-end mechanisms which use   digitally signed messages rather than depending on the integrity of   the transport system.   Efforts to make it more difficult for users to set envelope return   path and header "From" fields to point to valid addresses other than   their own are largely misguided: they frustrate legitimate   applications in which mail is sent by one user on behalf of another   or in which error (or normal) replies should be directed to a special   address.  (Systems that provide convenient ways for users to alter   these fields on a per-message basis should attempt to establish a   primary and permanent mailbox address for the user so that Sender   fields within the message data can be generated sensibly.)   This specification does not further address the authentication issues   associated with SMTP other than to advocate that useful functionality   not be disabled in the hope of providing some small margin of   protection against an ignorant user who is trying to fake mail.      NOTE: We have added additional material on communications security      and SMTP inSection 6.1.2 In a final specification, the above text      would be edited somewhat to reflect that fact.6.1.1.2. Blind Copies   Addresses that do not appear in the message headers may appear in the   RCPT commands to an SMTP server for a number of reasons.  The two   most common involve the use of a mailing address as a "list exploder"   (a single address that resolves into multiple addresses) and the   appearance of "blind copies".  Especially when more than one RCPT   command is present, and in order to avoid defeating some of the   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy   the full set of RCPT command arguments into the headers, either as   part of trace headers or as informational or private-extension   headers.  Since this rule is often violated in practice, and cannot   be enforced, sending SMTP systems that are aware of "bcc" use MAY   find it helpful to send each blind copy as a separate message   transaction containing only a single RCPT command.   There is no inherent relationship between either "reverse" (from   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP   transaction ("envelope") and the addresses in the headers.  Receiving   systems SHOULD NOT attempt to deduce such relationships and use themRescorla & Korver        Best Current Practice                 [Page 30]

RFC 3552           Security Considerations Guidelines          July 2003   to alter the headers of the message for delivery.  The popular   "Apparently-to" header is a violation of this principle as well as a   common source of unintended information disclosure and SHOULD NOT be   used.6.1.1.3. VRFY, EXPN, and Security   As discussed insection 3.5, individual sites may want to disable   either or both of VRFY or EXPN for security reasons.  As a corollary   to the above, implementations that permit this MUST NOT appear to   have verified addresses that are not, in fact, verified.  If a site   disables these commands for security reasons, the SMTP server MUST   return a 252 response, rather than a code that could be confused with   successful or unsuccessful verification.   Returning a 250 reply code with the address listed in the VRFY   command after having checked it only for syntax violates this rule.   Of course, an implementation that "supports" VRFY by always returning   550 whether or not the address is valid is equally not in   conformance.   Within the last few years, the contents of mailing lists have become   popular as an address information source for so-called "spammers."   The use of EXPN to "harvest" addresses has increased as list   administrators have installed protections against inappropriate uses   of the lists themselves.  Implementations SHOULD still provide   support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.   As authentication mechanisms are introduced into SMTP, some sites may   choose to make EXPN available only to authenticated requesters.      NOTE: It's not clear that disabling VRFY adds much protection,      since it's often possible to discover whether an address is valid      using RCPT TO.6.1.1.4. Information Disclosure in Announcements   There has been an ongoing debate about the tradeoffs between the   debugging advantages of announcing server type and version (and,   sometimes, even server domain name) in the greeting response or in   response to the HELP command and the disadvantages of exposing   information that might be useful in a potential hostile attack.  The   utility of the debugging information is beyond doubt.  Those who   argue for making it available point out that it is far better to   actually secure an SMTP server rather than hope that trying to   conceal known vulnerabilities by hiding the server's precise identity   will provide more protection.  Sites are encouraged to evaluate theRescorla & Korver        Best Current Practice                 [Page 31]

RFC 3552           Security Considerations Guidelines          July 2003   tradeoff with that issue in mind; implementations are strongly   encouraged to minimally provide for making type and version   information available in some way to other network hosts.6.1.1.5. Information Disclosure in Trace Fields   In some circumstances, such as when mail originates from within a LAN   whose hosts are not directly on the public Internet, trace   ("Received") fields produced in conformance with this specification   may disclose host names and similar information that would not   normally be available.  This ordinarily does not pose a problem, but   sites with special concerns about name disclosure should be aware of   it.  Also, the optional FOR clause should be supplied with caution or   not at all when multiple recipients are involved lest it   inadvertently disclose the identities of "blind copy" recipients to   others.6.1.1.6. Information Disclosure in Message Forwarding   As discussed insection 3.4, use of the 251 or 551 reply codes to   identify the replacement address associated with a mailbox may   inadvertently disclose sensitive information.  Sites that are   concerned about those issues should ensure that they select and   configure servers appropriately.6.1.1.7. Scope of Operation of SMTP Servers   It is a well-established principle that an SMTP server may refuse to   accept mail for any operational or technical reason that makes sense   to the site providing the server.  However, cooperation among sites   and installations makes the Internet possible.  If sites take   excessive advantage of the right to reject traffic, the ubiquity of   email availability (one of the strengths of the Internet) will be   threatened; considerable care should be taken and balance maintained   if a site decides to be selective about the traffic it will accept   and process.   In recent years, use of the relay function through arbitrary sites   has been used as part of hostile efforts to hide the actual origins   of mail.  Some sites have decided to limit the use of the relay   function to known or identifiable sources, and implementations SHOULD   provide the capability to perform this type of filtering.  When mail   is rejected for these or other policy reasons, a 550 code SHOULD be   used in response to EHLO, MAIL, or RCPT as appropriate.Rescorla & Korver        Best Current Practice                 [Page 32]

RFC 3552           Security Considerations Guidelines          July 20036.1.1.8. Inappropriate Usage [NEW]   SMTP itself provides no protection is provided against unsolicited   commercial mass e-mail (aka spam).  It is extremely difficult to tell   a priori whether a given message is spam or not.  From a protocol   perspective, spam is indistinguishable from other e-mail -- the   distinction is almost entirely social and often quite subtle.  (For   instance, is a message from a merchant from whom you've purchased   items before advertising similar items spam?) SMTP spam-suppression   mechanisms are generally limited to identifying known spam senders   and either refusing to service them or target them for   punishment/disconnection.  [RFC-2505] provides extensive guidance on   making SMTP servers spam-resistant.  We provide a brief discussion of   the topic here.   The primary tool for refusal to service spammers is the blacklist.   Some authority such as [MAPS] collects and publishes a list of known   spammers.  Individual SMTP servers then block the blacklisted   offenders (generally by IP address).   In order to avoid being blacklisted or otherwise identified, spammers   often attempt to obscure their identity, either simply by sending a   false SMTP identity or by forwarding their mail through an Open Relay   -- an SMTP server which will perform mail relaying for any sender.   As a consequence, there are now blacklists [ORBS] of open relays as   well.6.1.1.8.1. Closed Relaying [NEW]   To avoid being used for spam forwarding, many SMTP servers operate as   closed relays, providing relaying service only for clients who they   can identify.  Such relays should generally insist that senders   advertise a sending address consistent with their known identity.  If   the relay is providing service for an identifiable network (such as a   corporate network or an ISP's network) then it is sufficient to block   all other IP addresses).  In other cases, explicit authentication   must be used.  The two standard choices for this are TLS [STARTTLS]   and SASL [SASLSMTP].6.1.1.8.2. Endpoints [NEW]   Realistically, SMTP endpoints cannot refuse to deny service to   unauthenticated senders.  Since the vast majority of senders are   unauthenticated, this would break Internet mail interoperability.   The exception to this is when the endpoint server should only beRescorla & Korver        Best Current Practice                 [Page 33]

RFC 3552           Security Considerations Guidelines          July 2003   receiving mail from some other server which can itself receive   unauthenticated messages.  For instance, a company might operate a   public gateway but configure its internal servers to only talk to the   gateway.6.1.2. Communications security issues [NEW]   SMTP itself provides no communications security, and therefore a   large number of attacks are possible.  A passive attack is sufficient   to recover the text of messages transmitted with SMTP.  No endpoint   authentication is provided by the protocol.  Sender spoofing is   trivial, and therefore forging email messages is trivial.  Some   implementations do add header lines with hostnames derived through   reverse name resolution (which is only secure to the extent that it   is difficult to spoof DNS -- not very), although these header lines   are normally not displayed to users.  Receiver spoofing is also   fairly straight-forward, either using TCP connection hijacking or DNS   spoofing.  Moreover, since email messages often pass through SMTP   gateways, all intermediate gateways must be trusted, a condition   nearly impossible on the global Internet.   Several approaches are available for alleviating these threats.  In   order of increasingly high level in the protocol stack, we have:      SMTP over IPSEC      SMTP/TLS      S/MIME and PGP/MIME6.1.2.1. SMTP over IPSEC [NEW]   An SMTP connection run over IPSEC can provide confidentiality for the   message between the sender and the first hop SMTP gateway, or between   any pair of connected SMTP gateways.  That is to say, it provides   channel security for the SMTP connections.  In a situation where the   message goes directly from the client to the receiver's gateway, this   may provide substantial security (though the receiver must still   trust the gateway).  Protection is provided against replay attacks,   since the data itself is protected and the packets cannot be   replayed.   Endpoint identification is a problem, however, unless the receiver's   address can be directly cryptographically authenticated.  Sender   identification is not generally available, since generally only the   sender's machine is authenticated, not the sender himself.   Furthermore, the identity of the sender simply appears in the From   header of the message, so it is easily spoofable by the sender.   Finally, unless the security policy is set extremely strictly, there   is also an active downgrade to cleartext attack.Rescorla & Korver        Best Current Practice                 [Page 34]

RFC 3552           Security Considerations Guidelines          July 2003   Another problem with IPsec as a security solution for SMTP is the   lack of a standard IPsec API.  In order to take advantage of IPsec,   applications in general need to be able to instruct the IPsec   implementation about their security policies and discover what   protection has been applied to their connections.  Without a standard   API this is very difficult to do portably.   Implementors of SMTP servers or SMTP administrators MUST NOT assume   that IPsec will be available unless they have reason to believe that   it will be (such as the existence of preexisting association between   two machines).  However, it may be a reasonable procedure to attempt   to create an IPsec association opportunistically to a peer server   when mail is delivered.  Note that in cases where IPsec is used to   provide a VPN tunnel between two sites, this is of substantial   security value, particularly to the extent that confidentiality is   provided, subject to the caveats mentioned above.  Also see   [USEIPSEC] for general guidance on the applicability of IPsec.6.1.2.2. SMTP/TLS [NEW]   SMTP can be combined with TLS as described in [STARTTLS].  This   provides similar protection to that provided when using IPSEC.  Since   TLS certificates typically contain the server's host name, recipient   authentication may be slightly more obvious, but is still susceptible   to DNS spoofing attacks.  Notably, common implementations of TLS   contain a US exportable (and hence low security) mode.  Applications   desiring high security should ensure that this mode is disabled.   Protection is provided against replay attacks, since the data itself   is protected and the packets cannot be replayed.  [Note:  The   Security Considerations section of the SMTP over TLS document is   quite good and bears reading as an example of how to do things.]6.1.2.3. S/MIME and PGP/MIME [NEW]   S/MIME and PGP/MIME are both message oriented security protocols.   They provide object security for individual messages.  With various   settings, sender and recipient authentication and confidentiality may   be provided.  More importantly, the identification is not of the   sending and receiving machines, but rather of the sender and   recipient themselves.  (Or, at least, of cryptographic keys   corresponding to the sender and recipient.)  Consequently, end-to-end   security may be obtained.  Note, however, that no protection is   provided against replay attacks.  Note also that S/MIME and PGP/MIME   generally provide identifying marks for both sender and receiver.   Thus even when confidentiality is provided, traffic analysis is still   possible.Rescorla & Korver        Best Current Practice                 [Page 35]

RFC 3552           Security Considerations Guidelines          July 20036.1.3. Denial of Service [NEW]   None of these security measures provides any real protection against   denial of service.  SMTP connections can easily be used to tie up   system resources in a number of ways, including excessive port   consumption, excessive disk usage (email is typically delivered to   disk files), and excessive memory consumption (sendmail, for   instance, is fairly large, and typically forks a new process to deal   with each message.)   If transport- or application-layer security is used for SMTP   connections, it is possible to mount a variety of attacks on   individual connections using forged RSTs or other kinds of packet   injection.6.2. VRRP   The second example is from VRRP, the Virtual Router Redundance   Protocol ([VRRP]).  We reproduce here the Security Considerations   section from that document (with new section numbers).  Our comments   are indented and prefaced with 'NOTE:'.6.2.1. Security Considerations   VRRP is designed for a range of internetworking environments that may   employ different security policies.  The protocol includes several   authentication methods ranging from no authentication, simple clear   text passwords, and strong authentication using IP Authentication   with MD5 HMAC.  The details on each approach including possible   attacks and recommended environments follows.   Independent of any authentication type VRRP includes a mechanism   (setting TTL=255, checking on receipt) that protects against VRRP   packets being injected from another remote network.  This limits most   vulnerabilities to local attacks.      NOTE: The security measures discussed in the following sections      only provide various kinds of authentication.  No confidentiality      is provided at all.  This should be explicitly described as      outside the scope.6.2.1.1. No Authentication   The use of this authentication type means that VRRP protocol   exchanges are not authenticated.  This type of authentication SHOULD   only be used in environments were there is minimal security risk and   little chance for configuration errors (e.g., two VRRP routers on a   LAN).Rescorla & Korver        Best Current Practice                 [Page 36]

RFC 3552           Security Considerations Guidelines          July 20036.2.1.2. Simple Text Password   The use of this authentication type means that VRRP protocol   exchanges are authenticated by a simple clear text password.   This type of authentication is useful to protect against accidental   misconfiguration of routers on a LAN.  It protects against routers   inadvertently backing up another router.  A new router must first be   configured with the correct password before it can run VRRP with   another router.  This type of authentication does not protect against   hostile attacks where the password can be learned by a node snooping   VRRP packets on the LAN.  The Simple Text Authentication combined   with the TTL check makes it difficult for a VRRP packet to be sent   from another LAN to disrupt VRRP operation.   This type of authentication is RECOMMENDED when there is minimal risk   of nodes on a LAN actively disrupting VRRP operation.  If this type   of authentication is used the user should be aware that this clear   text password is sent frequently, and therefore should not be the   same as any security significant password.      NOTE: This section should be clearer.  The basic point is that no      authentication and Simple Text are only useful for a very limited      threat model, namely that none of the nodes on the local LAN are      hostile.  The TTL check prevents hostile nodes off-LAN from posing      as valid nodes, but nothing stops hostile nodes on-LAN from      impersonating authorized nodes.  This is not a particularly      realistic threat model in many situations.  In particular, it's      extremely brittle: the compromise of any node the LAN allows      reconfiguration of the VRRP nodes.6.2.1.3. IP Authentication Header   The use of this authentication type means the VRRP protocol exchanges   are authenticated using the mechanisms defined by the IP   Authentication Header [AH] using [HMAC].  This provides strong   protection against configuration errors, replay attacks, and packet   corruption/modification.   This type of authentication is RECOMMENDED when there is limited   control over the administration of nodes on a LAN.  While this type   of authentication does protect the operation of VRRP, there are other   types of attacks that may be employed on shared media links (e.g.,   generation of bogus ARP replies) which are independent from VRRP and   are not protected.Rescorla & Korver        Best Current Practice                 [Page 37]

RFC 3552           Security Considerations Guidelines          July 2003      NOTE: It's a mistake to have AH be a RECOMMENDED in this context.      Since AH is the only mechanism that protects VRRP against attack      from other nodes on the same LAN, it should be a MUST for cases      where there are untrusted nodes on the same network.  In any case,      AH should be a MUST implement.      NOTE: There's an important piece of security analysis that's only      hinted at in this document, namely the cost/benefit tradeoff of      VRRP authentication.   [The rest of this section is NEW material]   The threat that VRRP authentication is intended to prevent is an   attacker arranging to be the VRRP master.  This would be done by   joining the group (probably multiple times), gagging the master and   then electing oneself master.  Such a node could then direct traffic   in arbitrary undesirable ways.   However, it is not necessary for an attacker to be the VRRP master to   do this.  An attacker can do similar kinds of damage to the network   by forging ARP packets or (on switched networks) fooling the switch   VRRP authentication offers no real protection against these attacks.   Unfortunately, authentication makes VRRP networks very brittle in the   face of misconfiguration.  Consider what happens if two nodes are   configured with different passwords.  Each will reject messages from   the other and therefore both will attempt to be master.  This creates   substantial network instability.   This set of cost/benefit tradeoffs suggests that VRRP authentication   is a bad idea, since the incremental security benefit is marginal but   the incremental risk is high.  This judgment should be revisited if   the current set of non-VRRP threats are removed.7. Acknowledgments   This document is heavily based on a note written by Ran Atkinson in   1997.  That note was written after the IAB Security Workshop held in   early 1997, based on input from everyone at that workshop.  Some of   the specific text above was taken from Ran's original document, and   some of that text was taken from an email message written by Fred   Baker.  The other primary source for this document is specific   comments received from Steve Bellovin.  Early review of this document   was done by Lisa Dusseault and Mark Schertler.  Other useful comments   were received from Bill Fenner, Ned Freed, Lawrence Greenfield, Steve   Kent, Allison Mankin and Kurt Zeilenga.Rescorla & Korver        Best Current Practice                 [Page 38]

RFC 3552           Security Considerations Guidelines          July 20038. Normative References   [AH]       Kent, S. and R. Atkinson, "IP Authentication Header",RFC2402, November 1998.   [DNSSEC]   Eastlake, D., "Domain Name System Security Extensions",RFC 2535, March 1999.   [ENCOPT]   Tso, T., "Telnet Data Encryption Option",RFC 2946,              September, 2000.   [ESP]      Kent, S. and R. Atkinson, "IP Encapsulating Security              Payload (ESP)",RFC 2406, November 1998.   [GSS]      Linn, J., "Generic Security Services Application Program              Interface Version 2, Update 1",RFC 2743, January 2000.   [HTTP]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,              Masinter, L., Leach, P. and T. Berners-Lee, "HyperText              Transfer Protocol",RFC 2616, June 1999.   [HTTPTLS]  Rescorla, E., "HTTP over TLS",RFC 2818, May 2000.   [HMAC]     Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within              ESP and AH",RFC 2403, November 1998.   KERBEROS]  Kohl, J. and C. Neuman, "The Kerberos Network              Authentication Service (V5)",RFC 1510, September 1993.   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [OTP]      Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time              Password System", STD 61,RFC 2289, February 1998.   [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management              Protocol",RFC 2522, March 1999.   [PKIX]     Housley, R., Polk, W., Ford, W. and D. Solo, "Internet              X.509 "Public Key Infrastructure Certificate and              Certificate Restoration List (CRL) Profile",RFC 3280,              April 2002.   [RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors",RFC 2223, October 1997.   [RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",BCP 30,RFC 2505, February 1999.Rescorla & Korver        Best Current Practice                 [Page 39]

RFC 3552           Security Considerations Guidelines          July 2003   [RFC-2821] Klensin, J., "Simple Mail Transfer Protocol",RFC 2821,              April 2001.   [SASL]     Myers, J., "Simple Authentication and Security Layer              (SASL)",RFC 2222, October 1997.   [SPKI]     Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,              B. and T. Ylonen, "SPKI Certificate Theory",RFC 2693,              September 1999.   [SSH]      Ylonen, T., "SSH - Secure Login Connections Over the              Internet", 6th USENIX Security Symposium, p. 37-42, July              1996.   [SASLSMTP] Myers, J., "SMTP Service Extension for Authentication",RFC 2554, March 1999.   [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over              Transport Layer Security",RFC 3207, February 2002.   [S-HTTP]   Rescorla, E. and A. Schiffman, "The Secure HyperText              Transfer Protocol",RFC 2660, August 1999.   [S/MIME]   Ramsdell, B., Editor, "S/MIME Version 3 Message              Specification",RFC 2633, June 1999.   [TELNET]   Postel, J. and J. Reynolds, "Telnet Protocol              Specification", STD 8,RFC 854, May 1983.   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",RFC 2246, January 1999.   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D. and J.              Mikkelsen, "Transport Layer Security (TLS) Extensions",RFC 3546, May 2003.   [TCPSYN]   "TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory              CA-1996-21, 19 September 1996, CERT.http://www.cert.org/advisories/CA-1996-21.html   [UPGRADE]  Khare, R. and S. Lawrence, "Upgrading to TLS Within              HTTP/1.1",RFC 2817, May 2000.   [URL]      Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform              Resource Locators (URL)",RFC 1738, December 1994.Rescorla & Korver        Best Current Practice                 [Page 40]

RFC 3552           Security Considerations Guidelines          July 2003   [VRRP]     Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel,              D., Hunt, P., Higginson, P., Shand, M. and A. Lindemn,              "Virtual Router Redundancy Protocol",RFC 2338, April              1998.9. Informative References   [DDOS]     "Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28              December 1999, CERThttp://www.cert.org/advisories/CA-1999-17.html   [EKE]      Bellovin, S., Merritt, M., "Encrypted Key Exchange:              Password-based protocols secure against dictionary              attacks", Proceedings of the IEEE Symposium on Research in              Security and Privacy, May 1992.   [IDENT]    St. Johns, M. and M. Rose, "Identification Protocol",RFC1414, February 1993.   [INTAUTH]  Haller, N. and R. Atkinson, "On Internet Authentication",RFC 1704, October 1994.   [IPSPPROB] Bellovin, S. M., "Problem Areas for the IP Security              Protocols", Proceedings of the Sixth Usenix UNIX Security              Symposium, July 1996.   [KLEIN]    Klein, D.V., "Foiling the Cracker: A Survey of and              Improvements to Password Security",  1990.   [NNTP]     Kantor, B. and P. Lapsley, "Network News Transfer              Protocol",RFC 977, February 1986.   [POP]      Myers, J. and M. Rose, "Post Office Protocol - Version 3",              STD 53,RFC 1939, May 1996.   [SEQNUM]   Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP              Software", AT&T Bell Laboratories, CSTR 117, 1985.   [SOAP]     Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,              Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D., "Simple              Object Access Protocol (SOAP) 1.1", May 2000.   [SPEKE]    Jablon, D., "Strong Password-Only Authenticated Key              Exchange", Computer Communication Review, ACM SIGCOMM,              vol. 26, no. 5, pp. 5-26, October 1996.   [SRP]      Wu T., "The Secure Remote Password Protocol", ISOC NDSS              Symposium, 1998.Rescorla & Korver        Best Current Practice                 [Page 41]

RFC 3552           Security Considerations Guidelines          July 2003   [USEIPSEC] Bellovin, S.,"Guidelines for Mandating the Use of IPsec",              Work in Progress.   [WEP]      Borisov, N., Goldberg, I., Wagner, D., "Intercepting              Mobile Communications: The Insecurity of 802.11",http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf10. Security Considerations   This entire document is about security considerations.Rescorla & Korver        Best Current Practice                 [Page 42]

RFC 3552           Security Considerations Guidelines          July 2003Appendix 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. JohnsAuthors' Addresses   Eric Rescorla   RTFM, Inc.   2439 Alvin Drive   Mountain View, CA 94043   Phone: (650)-320-8549   EMail: ekr@rtfm.com   Brian Korver   Xythos Software, Inc.   77 Maiden Lane, 6th Floor   San Francisco, CA, 94108   Phone: (415)-248-3800   EMail: briank@xythos.com   Internet Architecture Board   IAB   EMail: iab@iab.orgRescorla & Korver        Best Current Practice                 [Page 43]

RFC 3552           Security Considerations Guidelines          July 2003Full Copyright Statement   Copyright (C) The Internet Society (2003).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Rescorla & Korver        Best Current Practice                 [Page 44]