<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> 
<!ENTITY rfc4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"> 
<!ENTITY rfc4033 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"> 
<!ENTITY rfc2946 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2946.xml"> 
<!ENTITY rfc4303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"> 
<!ENTITY rfc2743 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2743.xml"> 
<!ENTITY rfc7230 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"> 
<!ENTITY rfc2818 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"> 
<!ENTITY rfc2403 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2403.xml"> 
<!ENTITY rfc4120 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4120.xml"> 
<!ENTITY rfc2289 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2289.xml"> 
<!ENTITY rfc2522 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2522.xml"> 
<!ENTITY rfc5280 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"> 
<!ENTITY rfc7322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7322.xml"> 
<!ENTITY rfc2505 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2505.xml"> 
<!ENTITY rfc5231 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5231.xml"> 
<!ENTITY rfc4422 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4422.xml"> 
<!ENTITY rfc2693 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2693.xml"> 
<!ENTITY rfc4954 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4954.xml"> 
<!ENTITY rfc3207 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml"> 
<!ENTITY rfc2660 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2660.xml"> 
<!ENTITY rfc5751 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5751.xml"> 
<!ENTITY rfc0854 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0854.xml">
<!ENTITY rfc5322 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY rfc5246 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc2817 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2817.xml">
<!ENTITY rfc1738 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1738.xml">
<!ENTITY rfc5798 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5798.xml">
<!ENTITY rfc4253 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY rfc1414 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1414.xml">
<!ENTITY rfc1704 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1704.xml">
<!ENTITY rfc3977 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3977.xml"> 
<!ENTITY rfc0791 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"> 
<!ENTITY rfc1939 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1939.xml"> 
<!ENTITY rfc5406 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5406.xml"> 
<!ENTITY rfc5925 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml">
]>


<?rfc toc="yes"?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc rfcedstyle="yes"?>

<rfc ipr="trust200902" docName="draft-nir-saag-rfc3552bis-00" category="std">
  <front>
    <title abbrev="Security Considerations Guidelines">Guidelines for Writing RFC Text on Security Considerations</title>
    <author initials="Y." surname="Nir" fullname="Yoav Nir">
      <organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
      <address>
        <postal>
          <street>5 Hasolelim st.</street>
          <city>Tel Aviv</city>
          <code>6789735</code>
          <country>Israel</country>
        </postal>
        <email>ynir.ietf@gmail.com</email>
      </address>
    </author>
    <author initials='M.' surname='Westerlund' fullname='Magnus Westerlund'>
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Farogatan 6</street>
          <code>SE-164 80</code>
          <city>Stockholm</city>
          <country>Sweden</country>
        </postal>
        <phone>+46 10 714 82 87</phone>
        <email>magnus.westerlund@ericsson.com</email>
      </address>
    </author>
    <date year="2016"/>
    <area>Security Area</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t> 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.</t>
    </abstract>
  </front>
  <middle>
    <!-- ====================================================================== -->
    <section anchor="introduction" title="Introduction">
      <t> All RFCs are required by <xref target="RFC7322"/> 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.</t>
      <t> 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.</t>
      <section anchor="mustshouldmay" title="Conventions Used in This Document">
        <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
          "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
          interpreted as described in <xref target="RFC2119"/>.</t>
      </section>    
    </section>
    <section anchor="goals" title="The Goals of Security">
      <t> 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.</t>
      <t> 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.</t>
      <section anchor="comsec" title="Communication Security">
        <t> 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.</t>
        <section anchor="csconf" title="Confidentiality">
          <t> 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.</t>
          <t> 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.</t>
        </section>
        <section anchor="csdi" title="Data Integrity">
          <t> 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.</t>
          <t> 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.</t>
        </section>
        <section anchor="cspeerauth" title="Peer Entity Authentication">
          <t> 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.</t>
          <t> 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.</t>
          <t> 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.</t>
        </section>
      </section> 
      <section anchor="nonrep" title="Non-Repudiation"> 
        <t> 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.</t>
        <t> 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.</t>
        <t> Unfortunately, non-repudiation can be very difficult to achieve in practice 
          and naive approaches are generally inadequate.  <xref target="nonrepu" />   
          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.</t>
      </section> 
      <section anchor="syssec" title="Systems Security"> 
        <t> 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.</t>
        <section anchor="unauth" title="Unauthorized Usage">
          <t> 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.</t>
        </section>
        <section anchor="inapp" title="Inappropriate Usage">
          <t> 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.</t>
        </section>
        <section anchor="dos" title="Denial of Service">
          <t> 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.</t>
        </section>
      </section> 
    </section>
    <section anchor="itm" title="The Internet Threat Model">
      <t> 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.</t>
      <t> The Internet environment has a fairly well understood threat model. In general, 
        we assume that the end-systems engaging in a protocol exchange have not themselves 
        been compromised.  Protecting against an attack when one of the end-systems has 
        been compromised is extraordinarily difficult.  It is, however, possible to design
        protocols which minimize the extent of the damage done under these circumstances.</t>
      <t> 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.</t>
      <t> It's important to realize that the meaning of a PDU is different at different 
        levels.  At the IP level, a PDU means an IP packet.  At the TCP level, it means a 
        TCP segment.  At the application layer, it means some kind of application PDU. For 
        instance, at the level of email, it might either mean an <xref target="RFC5322" /> 
        message or a single SMTP command.  At the HTTP level, it might mean a request or 
        response.</t>
      <section anchor="ltm" title="Limited Threat Models">
        <t> 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 <xref
          target="RFC1704" />.</t>
        <t> By contrast, Morris' sequence number guessing attack <xref target="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.</t>
        <t> 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.</t>
      </section>
      <section anchor="passive" title="Passive Attacks">
        <t> In a passive attack, the attacker reads packets off the network but does not 
          write them.  The simplest way to mount such an attack is to simply be on the 
          same LAN as the victim.  On most common LAN configurations, including Ethernet, 
          802.3, and FDDI, any machine on the wire can read all traffic destined for any 
          other machine on the 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.</t>
        <t> 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.</t>
        <t> 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 <xref target="WEP"/>.</t>
        <t> 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.</t>
        <section anchor="confid" title="Confidentiality Violations">
          <t> 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.</t>
        </section>
        <section anchor="sniff" title="Password Sniffing">
          <t> Another example of a passive attack is PASSWORD SNIFFING.  Password sniffing 
            is directed towards obtaining unauthorized use of resources. Many protocols, 
            including TELNET <xref target="RFC0854" />, POP <xref target="RFC1939" />, and 
            NNTP <xref target="RFC3977" /> 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.</t>
          <t> 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.</t>
        </section>
        <section anchor="offline" title="Offline Cryptographic Attacks">
          <t> 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.</t>
          <t> 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 <xref target="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.</t>
          <t> 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.</t>
        </section>
      </section>
      <section anchor="active" title="Active Attacks">
        <t> 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.</t>
        <t> 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.</t>
        <t> 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.</t>
        <t> Note that not all active attacks require forging addresses.  For instance, the 
          TCP SYN denial of service attack <xref target="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.</t>
        <t> 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.</t>
      </section>
        <section anchor="replay" title="Replay Attacks">
          <t> 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.</t>
          <t> 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.</t>
        </section>
        <section anchor="insertion" title="Message Insertion">
          <t> 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.</t>
          <t> For example, a denial-of-service attack can be mounted by inserting a series 
            of spurious TCP SYN packets directed towards the target host. The target host 
            responds with its own SYN and allocates kernel data structures for the new 
            connection.  The attacker never completes the 3-way handshake, so the 
            allocated connection endpoints just sit there taking up kernel memory. Typical 
            TCP stack implementations only allow some limited number of connections in 
            this "half-open" state and when this limit is reached, no more connections can 
            be initiated, even from legitimate hosts.  Note that this attack is a blind 
            attack, since the attacker does not need to process the victim's SYNs.</t>
        </section>
        <section anchor="deletion" title="Message Deletion">
          <t> In a MESSAGE DELETION attack, the attacker removes a message from the wire.  
            Morris' sequence number guessing attack <xref target="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.</t>
        </section>
        <section anchor="modification" title="Message Modification">
          <t> 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.</t>
          <t> 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.</t>
          <t> Another interesting example of a cut-and-paste attack is provided by <xref 
            target="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.</t>
        </section>
        <section anchor="mitm" title="Man-In-The-Middle">
          <t> 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:</t><figure><artwork><![CDATA[
      What Alice and Bob think:
      Alice  <---------------------------------------------->  Bob

      What's happening:
      Alice  <---------------->  Attacker  <---------------->  Bob
       ]]></artwork></figure>
          <t> 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.</t>
          <t> 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.</t>
          <t> 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).</t>
        </section>
      <section anchor="topo" title="Topological Issues">
        <t> 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.</t>
        <section anchor="offpath" title="On-path versus off-path">
          <t> 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.</t>
          <t> 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.</t>
          <t> 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.</t>
        </section>
        <section anchor="linklocal" title="Link-local">
          <t> 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 <xref target="RFC0791"/>.  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.</t>
        </section>
      </section>
   </section>
   <section anchor="commonissues" title="Common Issues">
     <t> 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.</t>
     <section anchor="userauth" title="User Authentication">
       <t> 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.</t>
       <section anchor="uapass" title="Username/Password">
         <t> 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.</t>
       </section>
       <section anchor="uaotp" title="Challenge Response and One Time Passwords">
         <t> Systems which desire greater security than USERNAME/PASSWORD often employ 
           either a ONE TIME PASSWORD <xref target="RFC2289" /> 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.</t>
         <t> 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.</t>
         <t> 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.</t>
       </section>
       <section anchor="uaskey" title="Shared Keys">
         <t> 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.</t>
         <t> 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.</t>
       </section>
       <section anchor="uakdc" title="Key Distribution Centers">
         <t> 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 <xref target="RFC4120" />.</t>
       </section>
       <section anchor="uacert" title="Certificates">
         <t> A simple approach is to have all users have CERTIFICATES <xref 
           target="RFC5280" /> which they then use to authenticate in some 
           protocol-specific way, as in TLS <xref target="RFC5246" /> or S/MIME <xref 
           target="RFC5751" />.  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.</t>
       </section>
       <section anchor="uauncommon" title="Some Uncommon Systems">
         <t> 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 (<xref target="EKE"/>, 
           <xref target="SPEKE"/>, <xref target="SRP"/>) allow one to securely bootstrap a 
           user's password into a shared key which can be used as input to a cryptographic 
           protocol. One major obstacle to the deployment of these protocols has been that 
           their Intellectual Property status is extremely unclear.  Similarly, the user 
           can authenticate using public key certificates (e.g., S-HTTP client 
           authentication).  Typically these methods are used as part of a more complete 
           security protocol.</t>
       </section>
       <section anchor="uahost" title="Host Authentication">
         <t> Host authentication presents a special problem.  Quite commonly, the 
           addresses of services are presented using a DNS hostname, for instance as a 
           Uniform Resource Locator (URL) <xref target="RFC1738"/>.  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.</t>
         <t> 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.</t>
       </section>
     </section>
     <section anchor="gsf" title="Generic Security Frameworks">
       <t> 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 <xref target="RFC2743"/> and SASL 
         <xref target="RFC4422"/>.</t>
       <t> The generic framework approach has a number of problems.  First, it is highly 
         susceptible to DOWNGRADE ATTACKS.  In a downgrade attack, an active attacker 
         tampers with the negotiation in order to force the parties to negotiate weaker 
         protection than they otherwise would. It's possible to include an integrity check 
         after the negotiation and key establishment have both completed, but the strength 
         of this integrity check is necessarily limited to the weakest common algorithm.  
         This problem exists with any negotiation approach, but 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.</t>
       <t> 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.</t>
       <t> 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.</t>
     </section>
     <section anchor="nonrepu" title="Non-repudiation">
       <t> 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.</t>
       <t> 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.</t>
       <t> 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.</t>
       <t> All of these complications make non-repudiation a difficult service to deploy 
         in practice.</t>
     </section>
     <section anchor="authauth" title="Authorization vs. Authentication">
       <t> 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.</t>
       <t> 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.</t>
       <section anchor="acl" title="Access Control Lists">
         <t> 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.</t>
       </section>
       <section anchor="certs" title="Certificate Based Systems">
         <t> 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.</t>
         <t> With certificates, for instance, presenting a valid signature does not imply 
           authorization.  The signature must be backed by a certificate chain that 
           contains a trusted root, and that root must be trusted in the given context.  
           For instance, users who possess 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.</t>
         <t> 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 <xref target="RFC5280"/>, SPKI <xref 
           target="RFC2693"/>) or as a separate "Attribute Certificate".</t>
       </section>
     </section>
     <section anchor="trafficsec" title="Providing Traffic Security">
       <t> 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 <xref 
         target="RFC4033"/>, S/MIME <xref target="RFC5751"/> or S-HTTP <xref 
         target="RFC2660"/>.  Although this provides security which is most fitted to the 
         protocol, it also requires considerable effort to get right.</t>
       <t> Many protocols can be adequately secured using one of the available channel 
         security systems.  We'll discuss the two most common, IPsec <xref 
         target="RFC4302"/><xref target="RFC4303"/> and TLS <xref target="RFC5246"/>.</t>
       <section anchor="ipsec" title="IPsec">
         <t> 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.</t>
         <t> 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.</t>
         <t> 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.</t>
         <t> 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.</t>
         <t> 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.</t>
         <t> 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. <xref target="RFC5406"/> provides quite a bit of guidance on 
           when IPsec is a good choice.</t>
       </section>
       <section anchor="ssl" title="SSL/TLS">
         <t> 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.</t>
         <t> The two primary approaches used have a separate well-known port for TLS 
           connections (e.g., the HTTP over TLS port is 443) <xref target="RFC2818"/> or 
           to have a mechanism for negotiating upward from the base protocol to TLS as in 
           UPGRADE <xref target="RFC2817"/> or STARTTLS <xref target="RFC3207"/>. 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.</t>
         <t> 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 Authentication Option (TCP-AO) <xref
           target="RFC5925"/> are the preferred choices.</t>
         <section anchor="sslvh" title="Virtual Hosts">
           <t> 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 <xref 
             target="RFC7230"/>, since the server does not know which certificate to offer 
             the client during the TLS handshake.  The TLS hostname extension <xref 
             target="RFC5246"/> can be used to solve this problem, although it is too new 
             to have seen wide deployment.</t>
         </section>
         <section anchor="sslremoteauth" title="Remote Authentication and TLS">
           <t> 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.</t>
           <t> Unfortunately, this composition of SASL and TLS is less strong than one 
             would expect.  It's easy for an active attacker to hijack this connection.  
             The client man-in-the-middles the SSL connection (remember we're not 
             authenticating the server, which is what ordinarily prevents this attack) and 
             then simply proxies the SASL handshake.  From then on, it's as if the 
             connection were in the 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.</t>
           <t> 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.</t>
           <t> 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.</t>
         </section>
       </section>
       <section anchor="ssh" title="Remote Login">
         <t> 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 <xref target="RFC2946"/> prevents this expansion by foregoing 
           message integrity.</t>
         <t> When using remote terminal service, it's often desirable to securely perform 
           other sorts of communications services.  In addition to providing remote login, 
           SSH <xref target="RFC4253"/> 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.</t>
       </section>
     </section>
     <section anchor="antidos" title="Denial of Service Attacks and Countermeasures">
       <t> 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.</t>
     <t> 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 <xref target="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.</t>
     <t> 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.</t>
     <t> 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.</t>
       <section anchor="dosblind" title="Blind Denial of Service">
         <t> 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.</t>
       </section>
       <section anchor="dosddos" title="Distributed Denial of Service">
         <t> Even more dangerous are DISTRIBUTED denial of service attacks (DDoS) <xref 
           target="DDOS"/>.  In a DDoS the attacker arranges for a number of machines to 
           attack the target machine simultaneously.  Usually this is accomplished by 
           infecting a large number of machines with a program that allows remote 
           initiation of attacks.  The machines actually performing the attack are called 
           ZOMBIEs and are likely owned by unsuspecting third parties in an entirely 
           different location from the true attacker.  DDoS attacks can be very hard to 
           counter because the zombies often appear to be making legitimate protocol 
           requests and 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.</t>
       </section>
       <section anchor="dosavoid" title="Avoiding Denial of Service">
         <t> There are two common approaches to making denial of service attacks more 
           difficult:</t>
         <section anchor="puzzle" title="Make your attacker do more work than you do">
           <t> 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 <xref target="TCPSYN"/>.</t>
         </section>
         <section anchor="ret_rout" title="Make your attacker prove they can receive data from you">
           <t> 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.</t>
           <t> 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.</t>
         </section>
       </section>
       <section anchor="dossynflood" title="Example: TCP SYN Floods">
         <t> TCP/IP is vulnerable to SYN flood attacks (which are described in <xref 
           target="insertion"/>) 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).</t>
       </section>
       <section anchor="dosphoturis" title="Example: Photuris">
         <t> Photuris <xref target="RFC2522"/> 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.</t>
       </section>
     </section>
     <section anchor="objsec" title="Object vs. Channel Security">
       <t> 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.</t>
       <t> 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.</t>
       <t> 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.</t>
       <t> 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.</t>
       <t> The distinction isn't always clear-cut.  For example, S-HTTP provides object 
         level security for a single HTTP transaction, but a web page typically consists 
         of multiple HTTP transactions (the base page and numerous inline images).  Thus, 
         from the perspective of the total web page, this looks rather more like channel 
         security.  Object security for a web page would consist of security for the 
         transitive closure of the page and all its embedded content as a single unit.</t>
     </section>
     <section anchor="fw1" title="Firewalls">
       <t> 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.</t>
       <t> 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.</t>
       <t> 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 <xref target="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.</t>
     </section>
   </section>
   <section anchor="writing" title="Writing Security Considerations Sections">
     <t> 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.</t>
     <t> 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.</t>
     <t> Authors MUST describe<list style="numbers">
       <t> which attacks are out of scope (and why!)</t>
       <t> which attacks are in-scope<list style="format 2.%d.">
         <t> and the protocol is susceptible to</t>
         <t> and the protocol protects against</t></list></t></list></t>
     <t> 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.</t>
     <t> 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:<list>
       <t> 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.</t>
       <t> 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.</t></list></t>
     <t> It is insufficient to simply state that one's protocol should be run over some 
       lower layer security protocol.  If a system relies upon lower layer security 
       services for security, the protections those services are expected to provide MUST 
       be clearly specified. In addition, the resultant properties of the combined system 
       need to be specified.</t>
     <t> 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.</t>
     <t> 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.</t>
     <t> 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.</t>
     <t> 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.</t>
   </section>
   <section anchor="examples" title="Examples">
     <t> This section consists of some example security considerations sections, intended 
       to give the reader a flavor of what's intended by this document.</t>
     <t> 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.</t>
     <section anchor="smtp" title="SMTP">
       <t> When RFC 821 was written, Security Considerations sections were not required in 
         RFCs, and none is contained in that document. <xref target="RFC5231"/> updated 
         RFC 821 and added a detailed security considerations section. We reproduce here 
         the Security Considerations section from that document (with new section 
         numbers).  Our comments are indented and prefaced with 'NOTE:'.  We also add a 
         number of new sections to cover topics we consider important. Those sections are 
         marked with (NEW) in the section header.</t>
       <section anchor="smtp_sec_cons" title="Security Considerations">
         <section anchor="ssc_1" title="Mail Security and Spoofing">
           <t> 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 e.g., <xref 
             target="scs_3"/>).<list>
             <t> NOTE: One bad approach to sender authentication is IDENT <xref 
               target="RFC1414"/> 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.</t></list></t>
           <t> Various protocol extensions and configuration options that provide 
             authentication at the transport level (e.g., from an SMTP client to an SMTP 
             server) improve somewhat on the traditional situation described above.  
             However, unless they are accompanied by careful handoffs of responsibility in 
             a carefully-designed trust environment, they remain inherently weaker than 
             end-to-end mechanisms which use digitally signed messages rather than 
             depending on the integrity of the transport system.</t>
           <t> 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.)</t>
           <t> 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.<list>
             <t> NOTE: We have added additional material on communications security and 
               SMTP in <xref target="smtp_comsec"/> In a final specification, the above 
               text would be edited somewhat to reflect that fact.</t></list></t>
         </section>
         <section anchor="ssc_2" title="Blind Copies">
           <t> 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.</t>
           <t> There is no inherent relationship between either "reverse" (from MAIL, 
             SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction 
             ("envelope") and the addresses in the headers.  Receiving systems SHOULD NOT 
             attempt to deduce such relationships and use them to alter the headers of the 
             message for delivery.  The popular "Apparently-to" header is a violation of 
             this principle as well as a common source of unintended information 
             disclosure and SHOULD NOT be used.</t>
         </section>
         <section anchor="ssc_3" title="VRFY, EXPN, and Security">
           <t> As discussed in <xref target="offpath"/>, 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.</t>
           <t> 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.</t>
           <t> 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.<list>
             <t> 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.</t></list></t>
         </section>
         <section anchor="ssc_4" title="Information Disclosure in Announcements">
           <t> There has been an ongoing debate about the tradeoffs between the debugging 
             advantages of announcing server type and version (and, sometimes, even server 
             domain name) in the greeting response or in response to the HELP command and 
             the disadvantages of exposing information that might be useful in a potential 
             hostile attack.  The utility of the debugging information is beyond doubt.  
             Those who argue for making it available point out that it is far better to
             actually secure an SMTP server rather than hope that trying to conceal known 
             vulnerabilities by hiding the server's precise identity will provide more 
             protection. Sites are encouraged to evaluate the 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.</t>
         </section>
         <section anchor="ssc_5" title="Information Disclosure in Trace Fields">
           <t> 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.</t>
         </section>
         <section anchor="ssc_6" title="Information Disclosure in Message Forwarding">
           <t> As discussed in <xref target="topo"/>, 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.</t>
         </section>
         <section anchor="ssc_7" title="Scope of Operation of SMTP Servers">
           <t> 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.</t>
           <t> 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.</t>
         </section>
         <section anchor="ssc_8" title="Inappropriate Usage (NEW)">
           <t> 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. <xref target="RFC2505"/> provides extensive 
             guidance on making SMTP servers spam-resistant.  We provide a brief 
             discussion of the topic here.</t>
           <t> The primary tool for refusal to service spammers is the blacklist. Some 
             authority such as Mail Abuse Protection System (MAPS) collects and publishes 
             a list of known spammers.  Individual SMTP servers then block the blacklisted
             offenders (generally by IP address).</t>
           <t> 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 such as Open Relay Blocking System (ORBS) of open relays as
             well.</t>
           <section anchor="ssc_8_1" title="Closed Relaying (NEW)">
             <t> 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 through STARTTLS <xref target="RFC3207"/>
               and SASL <xref target="RFC4954"/>.</t>
           </section>
           <section anchor="ssc_8_2" title="Endpoints (NEW)">
             <t> Realistically, SMTP endpoints cannot refuse to deny service to 
               unauthenticated senders.  Since the vast majority of senders are 
               unauthenticated, this would break Internet mail interoperability. The 
               exception to this is when the endpoint server should only be 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.</t>
           </section>
         </section>
       </section>
       <section anchor="smtp_comsec" title="Communications security issues (NEW)">
         <t> 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.</t>
         <t> Several approaches are available for alleviating these threats.  In order of 
           increasingly high level in the protocol stack, we have:<list style="symbols">
           <t> SMTP over IPSEC</t>
           <t> SMTP/TLS</t>
           <t> S/MIME and PGP/MIME</t></list></t>
         <section anchor="scs_1" title="SMTP over IPSEC (NEW)">
           <t> 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.</t>
           <t> 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.</t>
           <t> 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.</t>
           <t> 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 <xref target="RFC5406"/> for general guidance on the 
             applicability of IPsec.</t>
         </section>
         <section anchor="scs_2" title="SMTP/TLS (NEW)">
           <t> SMTP can be combined with TLS as described in STARTTLS <xref 
             target="RFC3207"/>.  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.]</t>
         </section>
         <section anchor="scs_3" title="S/MIME and PGP/MIME (NEW)">
           <t> 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.</t>
         </section>
       </section>
       <section anchor="smtp_dos" title="Denial of Service (NEW)">
         <t> 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.)</t>
         <t> 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.</t>
       </section>
     </section>
     <section anchor="vrrp" title="VRRP">
       <t> The second example is from VRRP, the Virtual Router Redundance Protocol 
         <xref target="RFC5798"/>.  We reproduce here the Security Considerations section 
         from that document (with new section numbers).  Our comments are indented and 
         prefaced with 'NOTE:'.</t>
       <section anchor="vrrp_sec_cons" title="Security Considerations">
         <t> 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.</t>
         <t> 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.<list>
           <t> 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.</t></list></t>
         <section anchor="vsc_1" title="No Authentication">
           <t> 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).</t>
         </section>
         <section anchor="vsc_2" title="Simple Text Password">
           <t> The use of this authentication type means that VRRP protocol exchanges are 
             authenticated by a simple clear text password.</t>
           <t> 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.</t>
           <t> 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.<list>
             <t> 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.</t></list></t>
         </section>
         <section anchor="vsc_3" title="IP Authentication Header">
           <t> The use of this authentication type means the VRRP protocol exchanges are 
             authenticated using the mechanisms defined by the IP Authentication Header 
             <xref target="RFC4302"/> using HMAC <xref target="RFC2403"/>.  This provides 
             strong protection against configuration errors, replay attacks, and packet 
             corruption/modification.</t>
           <t> 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.<list>
             <t> 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.</t>
             <t> 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.</t></list></t>
           <t> [The rest of this section is NEW material]</t>
           <t> 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.</t>
           <t> 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.</t>
           <t> 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.</t>
           <t> 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.</t>
         </section>
       </section>
     </section>
   </section>
   <section anchor="ack" title="Acknowledgments">
     <t> The previous version of this document was 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 that 
       document was specific comments received from Steve Bellovin.  Early review of that 
       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.</t>
     <t> The previous version of this document was edited by Eric Rescorla and Brian 
       Korver with inputs from the other then current members of the IAB.</t>
   </section>
   <section anchor="iana_considerations" title="IANA Considerations">
     <t> This document makes no requests of IANA.</t>
   </section>
   <section anchor="security_considerations" title="Security Considerations">
     <t> This entire document is about security considerations.</t>
   </section>
  </middle>
  <!-- ====================================================================== -->
  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc4302;
      &rfc4033;
      &rfc2946;
      &rfc4303;
      &rfc2743;
      &rfc7230;
      &rfc2403;
      &rfc4120;
      &rfc2289;
      &rfc5280;
      &rfc2505;
      &rfc5231;
      &rfc4422;
      &rfc4954;
      &rfc3207;
      &rfc5751;
      &rfc0854;
      &rfc5246;
      &rfc2817;
      &rfc5798;
      &rfc4253;
    </references>
    <references title="Informative References"> 
      &rfc1414;
      &rfc1704;
      &rfc3977;
      &rfc0791;
      &rfc5322;
      &rfc1939;
      &rfc5406;
      &rfc5925;
      &rfc2818;
      &rfc2522;
      &rfc2693;
      &rfc2660;
      &rfc7322;
      &rfc1738;
      <reference anchor="TCPSYN" target="http://www.cert.org/advisories/CA-1996-21.html">
        <front>
          <title>TCP SYN Flooding and IP Spoofing Attacks</title>
          <author/>
          <date day="19" month="September" year="1996" />
        </front>
        <seriesInfo name='CERT Advisory' value='CA-1996-21' />
        <format type='HTML' target='http://www.cert.org/advisories/CA-1996-21.html' />
      </reference> 
      <reference anchor="DDOS" target="http://www.cert.org/advisories/CA-1999-17.html">
        <front>
          <title>Denial-Of-Service Tools</title>
          <author />
          <date day="28" month="December" year="1999" />
        </front>
        <seriesInfo name='CERT Advisory' value='CA-1999-17' />
        <format type='HTML' target='http://www.cert.org/advisories/CA-1999-17.html' />
      </reference>
      <reference anchor="EKE">
        <front>
          <title>Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks</title>
          <author initials="S." surname="Bellovin" fullname="Steve Bellovin">
            <organization />
          </author>
          <author initials="M." surname="Merritt" fullname="M. Merritt">
            <organization />
          </author>
          <date month="May" year="1992" />
        </front>
        <seriesInfo name='Proc. IEEE Symp.' value='on Research in Security and Privacy' />
      </reference>
      <reference anchor="IPSPPROB">
        <front>
          <title>Problem Areas for the IP Security Protocols</title>
          <author initials="S. M." surname="Bellovin" fullname="Steve M. Bellovin">
            <organization />
          </author>
          <date month="July" year="1996" />
        </front>
        <seriesInfo name='Proceedings' value='of the Sixth Usenix UNIX Security Symposium' />
      </reference>
      <reference anchor="KLEIN">
        <front>
          <title>Foiling the Cracker: A Survey of and Improvements to Password Security</title>
          <author initials="D. V." surname="Klein" fullname="Daniel V. Klein">
            <organization />
          </author>
          <date month="August" year="1990" />
        </front>
        <seriesInfo name='Proceedings' value='of the Second Usenix UNIX Security Workshop' />
      </reference>
      <reference anchor="SEQNUM">
        <front>
          <title>A Weakness in the 4.2 BSD UNIX TCP/IP Software</title>
          <author initials="R. T." surname="Morris" fullname="Robert T. Morris">
            <organization />
          </author>
          <date year="1985" />
        </front>
        <seriesInfo name='AT&amp;T Bell Laboratories, CSTR' value='117' />
      </reference>
      <reference anchor="SOAP">
        <front>
          <title>Simple Object Access Protocol (SOAP) 1.1</title>
          <author initials="D" surname="Box" fullname="Don Box">
            <organization />
          </author>
          <author initials="D" surname="Ehnebuske" fullname="David Ehnebuske">
            <organization />
          </author>
          <author initials="G" surname="Kakivaya" fullname="Gopal Kakivaya">
            <organization />
          </author>
          <author initials="A" surname="Layman" fullname="Andrew Layman">
            <organization />
          </author>
          <author initials="N" surname="Mendelsohn" fullname="Noah Mendelsohn">    
            <organization />
          </author>
          <author initials="H" surname="Nielsen" fullname="Henrik Frystyk Nielsen">
            <organization />
          </author>
          <author initials="S" surname="Thatte" fullname="Satish Thatte">
            <organization />
          </author>
          <author initials="D" surname="Winer" fullname="Dave Winer">
            <organization />
          </author>
          <date month="May" day="8" year="2000" />
        </front>
        <seriesInfo name="W3C NOTE" value="NOTE-SOAP-20000508" />
        <format type="HTML" target="http://www.w3.org/TR/2000/NOTE-SOAP-20000508" />
      </reference>
      <reference anchor="SPEKE">
        <front>
          <title>The SPEKE Password-Based Key Agreement Methods</title>
          <author initials="D" surname="Jablon" fullname="David Jablon">
            <organization/>
          </author>
          <date month="November" day="11" year="2002"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-jablon-speke-02"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-jablon-speke-02.txt"/>
      </reference>
      <reference anchor="SRP">
        <front>
          <title>The Secure Remote Password Protocol</title>
          <author initials="T" surname="Wu" fullname="Tom Wu">
            <organization>Stanford University</organization>
          </author>
          <date year="1998"/>
        </front>
        <seriesInfo name="ISOC NDSS Symposium" value=""/>
        <format type="HTML" target="http://srp.stanford.edu/ndss.html"/>
      </reference>      
      <reference anchor="WEP">
        <front>
          <title>Intercepting Mobile Communications: The Insecurity of 802.11</title>
          <author initials="N" surname="Borisov" fullname="Nikita Borisov">
            <organization>UC Berkeley</organization>
          </author>
          <author initials="I" surname="Goldberg" fullname="Ian Goldberg">
            <organization>Zero-Knowledge Systems</organization>
          </author>
          <author initials="D" surname="Wagner" fullname="David Wagner">
            <organization>UC Berkeley</organization>
          </author>
          <date month="July" year="2001"/>
        </front>
        <seriesInfo name="proceedings of the Seventh Annual International Conference on Mobile Computing And Networking" value=""/>
        <format type="PDF" target="http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf"/>
      </reference>      
    </references>
    <!-- ====================================================================== -->
  </back>
</rfc>

