as in [UPGRADE] or [STARTTLS]. When an upward negotiation strategy
is used, care must be taken to ensure that an attacker can not force
a clear connection when both parties wish to use TLS.
Note that TLS depends upon a reliable protocol such as TCP or SCTP.
This produces two notable difficulties. First, it cannot be used to
secure datagram protocols that use UDP. Second, TLS is susceptible
to IP layer attacks that IPsec is not. Typically, these attacks take
some form of denial of service or connection assassination. For
instance, an attacker might forge a TCP RST to shut down SSL
connections. TLS has mechanisms to detect truncation attacks but
these merely allow the victim to know he is being attacked and do not
provide connection survivability in the face of such attacks. By
contrast, if IPsec were being used, such a forged RST could be
rejected without affecting the TCP connection. If forged RSTs or
other such attacks on the TCP connection are a concern, then AH/ESP
or the TCP MD5 option [TCPMD5] are the preferred choices.
4.5.2.1. Virtual Hosts
If the "separate ports" approach to TLS is used, then TLS will be
negotiated before any application-layer traffic is sent. This can
cause a problem with protocols that use virtual hosts, such as
[HTTP], since the server does not know which certificate to offer the
client during the TLS handshake. The TLS hostname extension [TLSEXT]
can be used to solve this problem, although it is too new to have
seen wide deployment.
4.5.2.2. Remote Authentication and TLS
One difficulty with using TLS is that the server is authenticated via
a certificate. This can be inconvenient in environments where
previously the only form of authentication was a password shared
between client and server. It's tempting to use TLS without an
authenticated server (i.e., with anonymous DH or a self-signed RSA
certificate) and then authenticate via some challenge-response
mechanism such as SASL with CRAM-MD5.
Unfortunately, this composition of SASL and TLS is less strong than
one would expect. It's easy for an active attacker to hijack this
connection. The client man-in-the-middles the SSL connection
(remember we're not authenticating the server, which is what
ordinarily prevents this attack) and then simply proxies the SASL
handshake. From then on, it's as if the connection were in the
clear, at least as far as that attacker is concerned. In order to
prevent this attack, the client needs to verify the server's
certificate.
However, if the server is authenticated, challenge-response becomes
less desirable. If you already have a hardened channel then simple
passwords are fine. In fact, they're arguably superior to
challenge-response since they do not require that the password be
stored in the clear on the server. Thus, compromise of the key file
with challenge-response systems is more serious than if simple
passwords were used.
Note that if the client has a certificate than SSL-based client
authentication can be used. To make this easier, SASL provides the
EXTERNAL mechanism, whereby the SASL client can tell the server
"examine the outer channel for my identity". Obviously, this is not
subject to the layering attacks described above.
4.5.3. Remote Login
In some special cases it may be worth providing channel-level
security directly in the application rather than using IPSEC or
SSL/TLS. One such case is remote terminal security. Characters are
typically delivered from client to server one character at a time.
Since SSL/TLS and AH/ESP authenticate and encrypt every packet, this
can mean a data expansion of 20-fold. The telnet encryption option
[ENCOPT] prevents this expansion by foregoing message integrity.
When using remote terminal service, it's often desirable to securely
perform other sorts of communications services. In addition to
providing remote login, SSH [SSH] also provides secure port
forwarding for arbitrary TCP ports, thus allowing users run arbitrary
TCP-based applications over the SSH channel. Note that SSH Port
Forwarding can be security issue if it is used improperly to
circumvent firewall and improperly expose insecure internal
applications to the outside world.
4.6. Denial of Service Attacks and Countermeasures
Denial of service attacks are all too frequently viewed as an fact of
life. One problem is that an attacker can often choose from one of
many denial of service attacks to inflict upon a victim, and because
most of these attacks cannot be thwarted, common wisdom frequently
assumes that there is no point protecting against one kind of denial
of service attack when there are many other denial of service attacks
that are possible but that cannot be prevented.
However, not all denial of service attacks are equal and more
importantly, it is possible to design protocols so that denial of
service attacks are made more difficult, if not impractical. Recent
SYN flood attacks [TCPSYN] demonstrate both of these properties: SYN
flood attacks are so easy, anonymous, and effective that they are
more attractive to attackers than other attacks; and because the
design of TCP enables this attack.
Because complete DoS protection is so difficult, security against DoS
must be dealt with pragmatically. In particular, some attacks which
would be desirable to defend against cannot be defended against
economically. The goal should be to manage risk by defending against
attacks with sufficiently high ratios of severity to cost of defense.
Both severity of attack and cost of defense change as technology
changes and therefore so does the set of attacks which should be
defended against.
Authors of internet standards MUST describe which denial of service
attacks their protocol is susceptible to. This description MUST
include the reasons it was either unreasonable or out of scope to
attempt to avoid these denial of service attacks.
4.6.1. Blind Denial of Service
BLIND denial of service attacks are particularly pernicious. With a
blind attack the attacker has a significant advantage. If the
attacker must be able to receive traffic from the victim, then he
must either subvert the routing fabric or use his own IP address.
Either provides an opportunity for the victim to track the attacker
and/or filter out his traffic. With a blind attack the attacker can
use forged IP addresses, making it extremely difficult for the victim
to filter out his packets. The TCP SYN flood attack is an example of
a blind attack. Designers should make every attempt possible to
prevent blind denial of service attacks.
4.6.2. Distributed Denial of Service
Even more dangerous are DISTRIBUTED denial of service attacks (DDoS)
[DDOS]. In a DDoS the attacker arranges for a number of machines to
attack the target machine simultaneously. Usually this is
accomplished by infecting a large number of machines with a program
that allows remote initiation of attacks. The machines actually
performing the attack are called ZOMBIEs and are likely owned by
unsuspecting third parties in an entirely different location from the
true attacker. DDoS attacks can be very hard to counter because the
zombies often appear to be making legitimate protocol requests and
simply crowd out the real users. DDoS attacks can be difficult to
thwart, but protocol designers are expected to be cognizant of these
forms of attack while designing protocols.
4.6.3. Avoiding Denial of Service
There are two common approaches to making denial of service attacks
more difficult:
4.6.3.1. Make your attacker do more work than you do
If an attacker consumes more of his resources than yours when
launching an attack, attackers with fewer resources than you will be
unable to launch effective attacks. One common technique is to
require the attacker perform a time-intensive operation, such as a
cryptographic operation. Note that an attacker can still mount a
denial of service attack if he can muster substantially sufficient
CPU power. For instance, this technique would not stop the
distributed attacks described in [TCPSYN].
4.6.3.2. Make your attacker prove they can receive data from you
A blind attack can be subverted by forcing the attacker to prove that
they can can receive data from the victim. A common technique is to
require that the attacker reply using information that was gained
earlier in the message exchange. If this countermeasure is used, the
attacker must either use his own address (making him easy to track)
or to forge an address which will be routed back along a path that
traverses the host from which the attack is being launched.
Hosts on small subnets are thus useless to the attacker (at least in
the context of a spoofing attack) because the attack can be traced
back to a subnet (which should be sufficient for locating the
attacker) so that anti-attack measures can be put into place (for
instance, a boundary router can be configured to drop all traffic
from that subnet). A common technique is to require that the
attacker reply using information that was gained earlier in the
message exchange.
4.6.4. Example: TCP SYN Floods
TCP/IP is vulnerable to SYN flood attacks (which are described in
section 3.3.2) because of the design of the 3-way handshake. First,
an attacker can force a victim to consume significant resources (in
this case, memory) by sending a single packet. Second, because the
attacker can perform this action without ever having received data
from the victim, the attack can be performed anonymously (and
therefore using a large number of forged source addresses).
4.6.5. Example: Photuris
[PHOTURIS] specifies an anti-clogging mechanism that prevents attacks
on Photuris that resemble the SYN flood attack. Photuris employs a
time-variant secret to generate a "cookie" which is returned to the
attacker. This cookie must be returned in subsequent messages for
the exchange to progress. The interesting feature is that this
cookie can be regenerated by the victim later in the exchange, and
thus no state need be retained by the victim until after the attacker
has proven that he can receive packets from the victim.
4.7. Object vs. Channel Security
It's useful to make the conceptual distinction between object
security and channel security. Object security refers to security
measures which apply to entire data objects. Channel security
measures provide a secure channel over which objects may be carried
transparently but the channel has no special knowledge about object
boundaries.
Consider the case of an email message. When it's carried over an
IPSEC or TLS secured connection, the message is protected during
transmission. However, it is unprotected in the receiver's mailbox,
and in intermediate spool files along the way. Moreover, since mail
servers generally run as a daemon, not a user, authentication of
messages generally merely means authentication of the daemon not the
user. Finally, since mail transport is hop-by-hop, even if the user
authenticates to the first hop relay the authentication can't be
safely verified by the receiver.
By contrast, when an email message is protected with S/MIME or
OpenPGP, the entire message is encrypted and integrity protected
until it is examined and decrypted by the recipient. It also
provides strong authentication of the actual sender, as opposed to
the machine the message came from. This is object security.
Moreover, the receiver can prove the signed message's authenticity to
a third party.
Note that the difference between object and channel security is a
matter of perspective. Object security at one layer of the protocol
stack often looks like channel security at the next layer up. So,
from the perspective of the IP layer, each packet looks like an
individually secured object. But from the perspective of a web
client, IPSEC just provides a secure channel.
The distinction isn't always clear-cut. For example, S-HTTP provides
object level security for a single HTTP transaction, but a web page
typically consists of multiple HTTP transactions (the base page and
numerous inline images). Thus, from the perspective of the total web
page, this looks rather more like channel security. Object security
for a web page would consist of security for the transitive closure
of the page and all its embedded content as a single unit.
4.8. Firewalls and Network Topology
It's common security practice in modern networks to partition the
network into external and internal networks using a firewall. The
internal network is then assumed to be secure and only limited
security measures are used there. The internal portion of such a
network is often called a WALLED GARDEN.
Internet protocol designers cannot safely assume that their protocols
will be deployed in such an environment, for three reasons. First,
protocols which were originally designed to be deployed in closed
environments often are later deployed on the Internet, thus creating
serious vulnerabilities.
Second, networks which appear to be topologically disconnected may
not be. One reason may be that the network has been reconfigured to
allow access by the outside world. Moreover, firewalls are
increasingly passing generic application layer protocols such as
[SOAP] or [HTTP]. Network protocols which are based on these generic
protocols cannot in general assume that a firewall will protect them.
Finally, one of the most serious security threats to systems is from
insiders, not outsiders. Since insiders by definition have access to
the internal network, topological protections such as firewalls will
not protect them.
5. Writing Security Considerations Sections
While it is not a requirement that any given protocol or system be
immune to all forms of attack, it is still necessary for authors to
consider as many forms as possible. Part of the purpose of the
Security Considerations section is to explain what attacks are out of
scope and what countermeasures can be applied to defend against them.
In
There should be a clear description of the kinds of threats on the
described protocol or technology. This should be approached as an
effort to perform "due diligence" in describing all known or
foreseeable risks and threats to potential implementers and users.
Authors MUST describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
At least the following forms of attack MUST be considered:
eavesdropping, replay, message insertion, deletion, modification, and
man-in-the-middle. Potential denial of service attacks MUST be
identified as well. If the protocol incorporates cryptographic
protection mechanisms, it should be clearly indicated which portions
of the data are protected and what the protections are (i.e.,
integrity only, confidentiality, and/or endpoint authentication,
etc.). Some indication should also be given to what sorts of attacks
the cryptographic protection is susceptible. Data which should be
held secret (keying material, random seeds, etc.) should be clearly
labeled.
If the technology involves authentication, particularly user-host
authentication, the security of the authentication method MUST be
clearly specified. That is, authors MUST document the assumptions
that the security of this authentication method is predicated upon.
For instance, in the case of the UNIX username/password login method,
a statement to the effect of:
Authentication in the system is secure only to the extent that it
is difficult to guess or obtain a ASCII password that is a maximum
of 8 characters long. These passwords can be obtained by sniffing
telnet sessions or by running the 'crack' program using the
contents of the /etc/passwd file. Attempts to protect against
on-line password guessing by (1) disconnecting after several
unsuccessful login attempts and (2) waiting between successive
password prompts is effective only to the extent that attackers
are impatient.
Because the /etc/passwd file maps usernames to user ids, groups,
etc. it must be world readable. In order to permit this usage but
make running crack more difficult, the file is often split into
/etc/passwd and a 'shadow' password file. The shadow file is not
world readable and contains the encrypted password. The regular
/etc/passwd file contains a dummy password in its place.
It is insufficient to simply state that one's protocol should be run
over some lower layer security protocol. If a system relies upon
lower layer security services for security, the protections those
services are expected to provide MUST be clearly specified. In
addition, the resultant properties of the combined system need to be
specified.
Note: In general, the IESG will not approve standards track protocols
which do not provide for strong authentication, either internal to
the protocol or through tight binding to a lower layer security
protocol.
The threat environment addressed by the Security Considerations
section MUST at a minimum include deployment across the global
Internet across multiple administrative boundaries without assuming
that firewalls are in place, even if only to provide justification
for why such consideration is out of scope for the protocol. It is
not acceptable to only discuss threats applicable to LANs and ignore
the broader threat environment. All IETF standards-track protocols
are considered likely to have deployment in the global Internet. In
some cases, there might be an Applicability Statement discouraging
use of a technology or protocol in a particular environment.
Nonetheless, the security issues of broader deployment should be
discussed in the document.
There should be a clear description of the residual risk to the user
or operator of that protocol after threat mitigation has been
deployed. Such risks might arise from compromise in a related
protocol (e.g., IPsec is useless if key management has been
compromised), from incorrect implementation, compromise of the
security technology used for risk reduction (e.g., a cipher with a
40-bit key), or there might be risks that are not addressed by the
protocol specification (e.g., denial of service attacks on an
underlying link protocol). Particular care should be taken in
situations where the compromise of a single system would compromise
an entire protocol. For instance, in general protocol designers
assume that end-systems are inviolate and don't worry about physical
attack. However, in cases (such as a certificate authority) where
compromise of a single system could lead to widespread compromises,
it is appropriate to consider systems and physical security as well.
There should also be some discussion of potential security risks
arising from potential misapplications of the protocol or technology
described in the RFC. This might be coupled with an Applicability
Statement for that RFC.
6. Examples
This section consists of some example security considerations
sections, intended to give the reader a flavor of what's intended by
this document.
The first example is a 'retrospective' example, applying the criteria
of this document to an existing widely deployed protocol, SMTP. The
second example is a good security considerations section clipped from
a current protocol.
6.1. SMTP
When RFC821 was written, Security Considerations sections were not
required in RFCs, and none is contained in that document. [RFC2821]
updated RFC821 and added a detailed security considerations section.
We reproduce here the Security Considerations section from that
document (with new section numbers). Our comments are indented and
prefaced with 'NOTE:'. We also add a number of new sections to cover
topics we consider important. Those sections are marked with [NEW]
in the section header.
6.1.1. Security Considerations
6.1.1.1. Mail Security and Spoofing
SMTP mail is inherently insecure in that it is feasible for even
fairly casual users to negotiate directly with receiving and relaying
SMTP servers and create messages that will trick a naive recipient
into believing that they came from somewhere else. Constructing such
a message so that the "spoofed" behavior cannot be detected by an
expert is somewhat more difficult, but not sufficiently so as to be a
deterrent to someone who is determined and knowledgeable.
Consequently, as knowledge of Internet mail increases, so does the
knowledge that SMTP mail inherently cannot be authenticated, or
integrity checks provided, at the transport level. Real mail
security lies only in end-to-end methods involving the message
bodies, such as those which use digital signatures (see [14] and,
e.g., PGP [4] or S/MIME [31]).
NOTE: One bad approach to sender authentication is [IDENT] in
which the receiving mail server contacts the alleged sender and
asks for the username of the sender. This is a bad idea for a
number of reasons, including but not limited to relaying, TCP
connection hijacking, and simple lying by the origin server.
Aside from the fact that IDENT is of low security value, use of
IDENT by receiving sites can lead to operational problems. Many
sending sites blackhole IDENT requests, thus causing mail to be
held until the receiving server's IDENT request times out.
Various protocol extensions and configuration options that provide
authentication at the transport level (e.g., from an SMTP client to
an SMTP server) improve somewhat on the traditional situation
described above. However, unless they are accompanied by careful
handoffs of responsibility in a carefully-designed trust environment,
they remain inherently weaker than end-to-end mechanisms which use
digitally signed messages rather than depending on the integrity of
the transport system.
Efforts to make it more difficult for users to set envelope return
path and header "From" fields to point to valid addresses other than
their own are largely misguided: they frustrate legitimate
applications in which mail is sent by one user on behalf of another
or in which error (or normal) replies should be directed to a special
address. (Systems that provide convenient ways for users to alter
these fields on a per-message basis should attempt to establish a
primary and permanent mailbox address for the user so that Sender
fields within the message data can be generated sensibly.)
This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled in the hope of providing some small margin of
protection against an ignorant user who is trying to fake mail.
NOTE: We have added additional material on communications security
and SMTP in Section 6.1.2 In a final specification, the above text
would be edited somewhat to reflect that fact.
6.1.1.2. Blind Copies
Addresses that do not appear in the message headers may appear in the
RCPT commands to an SMTP server for a number of reasons. The two
most common involve the use of a mailing address as a "list exploder"
(a single address that resolves into multiple addresses) and the
appearance of "blind copies". Especially when more than one RCPT
command is present, and in order to avoid defeating some of the
purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
the full set of RCPT command arguments into the headers, either as
part of trace headers or as informational or private-extension
headers. Since this rule is often violated in practice, and cannot
be enforced, sending SMTP systems that are aware of "bcc" use MAY
find it helpful to send each blind copy as a separate message
transaction containing only a single RCPT command.
There is no inherent relationship between either "reverse" (from
MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
transaction ("envelope") and the addresses in the headers. Receiving
systems SHOULD NOT attempt to deduce such relationships and use them
to alter the headers of the message for delivery. The popular
"Apparently-to" header is a violation of this principle as well as a
common source of unintended information disclosure and SHOULD NOT be
used.
6.1.1.3. VRFY, EXPN, and Security
As discussed in section 3.5, individual sites may want to disable
either or both of VRFY or EXPN for security reasons. As a corollary
to the above, implementations that permit this MUST NOT appear to
have verified addresses that are not, in fact, verified. If a site
disables these commands for security reasons, the SMTP server MUST
return a 252 response, rather than a code that could be confused with
successful or unsuccessful verification.
Returning a 250 reply code with the address listed in the VRFY
command after having checked it only for syntax violates this rule.
Of course, an implementation that "supports" VRFY by always returning
550 whether or not the address is valid is equally not in
conformance.
Within the last few years, the contents of mailing lists have become
popular as an address information source for so-called "spammers."
The use of EXPN to "harvest" addresses has increased as list
administrators have installed protections against inappropriate uses
of the lists themselves. Implementations SHOULD still provide
support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
As authentication mechanisms are introduced into SMTP, some sites may
choose to make EXPN available only to authenticated requesters.
NOTE: It's not clear that disabling VRFY adds much protection,
since it's often possible to discover whether an address is valid
using RCPT TO.
6.1.1.4. Information Disclosure in Announcements
There has been an ongoing debate about the tradeoffs between the
debugging advantages of announcing server type and version (and,
sometimes, even server domain name) in the greeting response or in
response to the HELP command and the disadvantages of exposing
information that might be useful in a potential hostile attack. The
utility of the debugging information is beyond doubt. Those who
argue for making it available point out that it is far better to
actually secure an SMTP server rather than hope that trying to
conceal known vulnerabilities by hiding the server's precise identity
will provide more protection. Sites are encouraged to evaluate the
tradeoff with that issue in mind; implementations are strongly
encouraged to minimally provide for making type and version
information available in some way to other network hosts.
6.1.1.5. Information Disclosure in Trace Fields
In some circumstances, such as when mail originates from within a LAN
whose hosts are not directly on the public Internet, trace
("Received") fields produced in conformance with this specification
may disclose host names and similar information that would not
normally be available. This ordinarily does not pose a problem, but
sites with special concerns about name disclosure should be aware of
it. Also, the optional FOR clause should be supplied with caution or
not at all when multiple recipients are involved lest it
inadvertently disclose the identities of "blind copy" recipients to
others.
6.1.1.6. Information Disclosure in Message Forwarding
As discussed in section 3.4, use of the 251 or 551 reply codes to
identify the replacement address associated with a mailbox may
inadvertently disclose sensitive information. Sites that are
concerned about those issues should ensure that they select and
configure servers appropriately.
6.1.1.7. Scope of Operation of SMTP Servers
It is a well-established principle that an SMTP server may refuse to
accept mail for any operational or technical reason that makes sense
to the site providing the server. However, cooperation among sites
and installations makes the Internet possible. If sites take
excessive advantage of the right to reject traffic, the ubiquity of
email availability (one of the strengths of the Internet) will be
threatened; considerable care should be taken and balance maintained
if a site decides to be selective about the traffic it will accept
and process.
In recent years, use of the relay function through arbitrary sites
has been used as part of hostile efforts to hide the actual origins
of mail. Some sites have decided to limit the use of the relay
function to known or identifiable sources, and implementations SHOULD
provide the capability to perform this type of filtering. When mail
is rejected for these or other policy reasons, a 550 code SHOULD be
used in response to EHLO, MAIL, or RCPT as appropriate.
6.1.1.8. Inappropriate Usage [NEW]
SMTP itself provides no protection is provided against unsolicited
commercial mass e-mail (aka spam). It is extremely difficult to tell
a priori whether a given message is spam or not. From a protocol
perspective, spam is indistinguishable from other e-mail -- the
distinction is almost entirely social and often quite subtle. (For
instance, is a message from a merchant from whom you've purchased
items before advertising similar items spam?) SMTP spam-suppression
mechanisms are generally limited to identifying known spam senders
and either refusing to service them or target them for
punishment/disconnection. [RFC-2505] provides extensive guidance on
making SMTP servers spam-resistant. We provide a brief discussion of
the topic here.
The primary tool for refusal to service spammers is the blacklist.
Some authority such as [MAPS] collects and publishes a list of known
spammers. Individual SMTP servers then block the blacklisted
offenders (generally by IP address).
In order to avoid being blacklisted or otherwise identified, spammers
often attempt to obscure their identity, either simply by sending a
false SMTP identity or by forwarding their mail through an Open Relay
-- an SMTP server which will perform mail relaying for any sender.
As a consequence, there are now blacklists [ORBS] of open relays as
well.
6.1.1.8.1. Closed Relaying [NEW]
To avoid being used for spam forwarding, many SMTP servers operate as
closed relays, providing relaying service only for clients who they
can identify. Such relays should generally insist that senders
advertise a sending address consistent with their known identity. If
the relay is providing service for an identifiable network (such as a
corporate network or an ISP's network) then it is sufficient to block
all other IP addresses). In other cases, explicit authentication
must be used. The two standard choices for this are TLS [STARTTLS]
and SASL [SASLSMTP].
6.1.1.8.2. Endpoints [NEW]
Realistically, SMTP endpoints cannot refuse to deny service to
unauthenticated senders. Since the vast majority of senders are
unauthenticated, this would break Internet mail interoperability.
The exception to this is when the endpoint server should only be
receiving mail from some other server which can itself receive
unauthenticated messages. For instance, a company might operate a
public gateway but configure its internal servers to only talk to the
gateway.
6.1.2. Communications security issues [NEW]
SMTP itself provides no communications security, and therefore a
large number of attacks are possible. A passive attack is sufficient
to recover the text of messages transmitted with SMTP. No endpoint
authentication is provided by the protocol. Sender spoofing is
trivial, and therefore forging email messages is trivial. Some
implementations do add header lines with hostnames derived through
reverse name resolution (which is only secure to the extent that it
is difficult to spoof DNS -- not very), although these header lines
are normally not displayed to users. Receiver spoofing is also
fairly straight-forward, either using TCP connection hijacking or DNS
spoofing. Moreover, since email messages often pass through SMTP
gateways, all intermediate gateways must be trusted, a condition
nearly impossible on the global Internet.
Several approaches are available for alleviating these threats. In
order of increasingly high level in the protocol stack, we have:
SMTP over IPSEC
SMTP/TLS
S/MIME and PGP/MIME
6.1.2.1. SMTP over IPSEC [NEW]
An SMTP connection run over IPSEC can provide confidentiality for the
message between the sender and the first hop SMTP gateway, or between
any pair of connected SMTP gateways. That is to say, it provides
channel security for the SMTP connections. In a situation where the
message goes directly from the client to the receiver's gateway, this
may provide substantial security (though the receiver must still
trust the gateway). Protection is provided against replay attacks,
since the data itself is protected and the packets cannot be
replayed.
Endpoint identification is a problem, however, unless the receiver's
address can be directly cryptographically authenticated. Sender
identification is not generally available, since generally only the
sender's machine is authenticated, not the sender himself.
Furthermore, the identity of the sender simply appears in the From
header of the message, so it is easily spoofable by the sender.
Finally, unless the security policy is set extremely strictly, there
is also an active downgrade to cleartext attack.
Another problem with IPsec as a security solution for SMTP is the
lack of a standard IPsec API. In order to take advantage of IPsec,
applications in general need to be able to instruct the IPsec
implementation about their security policies and discover what
protection has been applied to their connections. Without a standard
API this is very difficult to do portably.
Implementors of SMTP servers or SMTP administrators MUST NOT assume
that IPsec will be available unless they have reason to believe that
it will be (such as the existence of preexisting association between
two machines). However, it may be a reasonable procedure to attempt
to create an IPsec association opportunistically to a peer server
when mail is delivered. Note that in cases where IPsec is used to
provide a VPN tunnel between two sites, this is of substantial
security value, particularly to the extent that confidentiality is
provided, subject to the caveats mentioned above. Also see
[USEIPSEC] for general guidance on the applicability of IPsec.
6.1.2.2. SMTP/TLS [NEW]
SMTP can be combined with TLS as described in [STARTTLS]. This
provides similar protection to that provided when using IPSEC. Since
TLS certificates typically contain the server's host name, recipient
authentication may be slightly more obvious, but is still susceptible
to DNS spoofing attacks. Notably, common implementations of TLS
contain a US exportable (and hence low security) mode. Applications
desiring high security should ensure that this mode is disabled.
Protection is provided against replay attacks, since the data itself
is protected and the packets cannot be replayed. [Note: The
Security Considerations section of the SMTP over TLS document is
quite good and bears reading as an example of how to do things.]
6.1.2.3. S/MIME and PGP/MIME [NEW]
S/MIME and PGP/MIME are both message oriented security protocols.
They provide object security for individual messages. With various
settings, sender and recipient authentication and confidentiality may
be provided. More importantly, the identification is not of the
sending and receiving machines, but rather of the sender and
recipient themselves. (Or, at least, of cryptographic keys
corresponding to the sender and recipient.) Consequently, end-to-end
security may be obtained. Note, however, that no protection is
provided against replay attacks. Note also that S/MIME and PGP/MIME
generally provide identifying marks for both sender and receiver.
Thus even when confidentiality is provided, traffic analysis is still
possible.
6.1.3. Denial of Service [NEW]
None of these security measures provides any real protection against
denial of service. SMTP connections can easily be used to tie up
system resources in a number of ways, including excessive port
consumption, excessive disk usage (email is typically delivered to
disk files), and excessive memory consumption (sendmail, for
instance, is fairly large, and typically forks a new process to deal
with each message.)
If transport- or application-layer security is used for SMTP
connections, it is possible to mount a variety of attacks on
individual connections using forged RSTs or other kinds of packet
injection.
6.2. VRRP
The second example is from VRRP, the Virtual Router Redundance
Protocol ([VRRP]). We reproduce here the Security Considerations
section from that document (with new section numbers). Our comments
are indented and prefaced with 'NOTE:'.
6.2.1. Security Considerations
VRRP is designed for a range of internetworking environments that may
employ different security policies. The protocol includes several
authentication methods ranging from no authentication, simple clear
text passwords, and strong authentication using IP Authentication
with MD5 HMAC. The details on each approach including possible
attacks and recommended environments follows.
Independent of any authentication type VRRP includes a mechanism
(setting TTL=255, checking on receipt) that protects against VRRP
packets being injected from another remote network. This limits most
vulnerabilities to local attacks.
NOTE: The security measures discussed in the following sections
only provide various kinds of authentication. No confidentiality
is provided at all. This should be explicitly described as
outside the scope.
6.2.1.1. No Authentication
The use of this authentication type means that VRRP protocol
exchanges are not authenticated. This type of authentication SHOULD
only be used in environments were there is minimal security risk and
little chance for configuration errors (e.g., two VRRP routers on a
LAN).
6.2.1.2. Simple Text Password
The use of this authentication type means that VRRP protocol
exchanges are authenticated by a simple clear text password.
This type of authentication is useful to protect against accidental
misconfiguration of routers on a LAN. It protects against routers
inadvertently backing up another router. A new router must first be
configured with the correct password before it can run VRRP with
another router. This type of authentication does not protect against
hostile attacks where the password can be learned by a node snooping
VRRP packets on the LAN. The Simple Text Authentication combined
with the TTL check makes it difficult for a VRRP packet to be sent
from another LAN to disrupt VRRP operation.
This type of authentication is RECOMMENDED when there is minimal risk
of nodes on a LAN actively disrupting VRRP operation. If this type
of authentication is used the user should be aware that this clear
text password is sent frequently, and therefore should not be the
same as any security significant password.
NOTE: This section should be clearer. The basic point is that no
authentication and Simple Text are only useful for a very limited
threat model, namely that none of the nodes on the local LAN are
hostile. The TTL check prevents hostile nodes off-LAN from posing
as valid nodes, but nothing stops hostile nodes on-LAN from
impersonating authorized nodes. This is not a particularly
realistic threat model in many situations. In particular, it's
extremely brittle: the compromise of any node the LAN allows
reconfiguration of the VRRP nodes.
6.2.1.3. IP Authentication Header
The use of this authentication type means the VRRP protocol exchanges
are authenticated using the mechanisms defined by the IP
Authentication Header [AH] using [HMAC]. This provides strong
protection against configuration errors, replay attacks, and packet
corruption/modification.
This type of authentication is RECOMMENDED when there is limited
control over the administration of nodes on a LAN. While this type
of authentication does protect the operation of VRRP, there are other
types of attacks that may be employed on shared media links (e.g.,
generation of bogus ARP replies) which are independent from VRRP and
are not protected.
NOTE: It's a mistake to have AH be a RECOMMENDED in this context.
Since AH is the only mechanism that protects VRRP against attack
from other nodes on the same LAN, it should be a MUST for cases
where there are untrusted nodes on the same network. In any case,
AH should be a MUST implement.
NOTE: There's an important piece of security analysis that's only
hinted at in this document, namely the cost/benefit tradeoff of
VRRP authentication.
[The rest of this section is NEW material]
The threat that VRRP authentication is intended to prevent is an
attacker arranging to be the VRRP master. This would be done by
joining the group (probably multiple times), gagging the master and
then electing oneself master. Such a node could then direct traffic
in arbitrary undesirable ways.
However, it is not necessary for an attacker to be the VRRP master to
do this. An attacker can do similar kinds of damage to the network
by forging ARP packets or (on switched networks) fooling the switch
VRRP authentication offers no real protection against these attacks.
Unfortunately, authentication makes VRRP networks very brittle in the
face of misconfiguration. Consider what happens if two nodes are
configured with different passwords. Each will reject messages from
the other and therefore both will attempt to be master. This creates
substantial network instability.
This set of cost/benefit tradeoffs suggests that VRRP authentication
is a bad idea, since the incremental security benefit is marginal but
the incremental risk is high. This judgment should be revisited if
the current set of non-VRRP threats are removed.
7. Acknowledgments
This document is heavily based on a note written by Ran Atkinson in
1997. That note was written after the IAB Security Workshop held in
early 1997, based on input from everyone at that workshop. Some of
the specific text above was taken from Ran's original document, and
some of that text was taken from an email message written by Fred
Baker. The other primary source for this document is specific
comments received from Steve Bellovin. Early review of this document
was done by Lisa Dusseault and Mark Schertler. Other useful comments
were received from Bill Fenner, Ned Freed, Lawrence Greenfield, Steve
Kent, Allison Mankin and Kurt Zeilenga.
8. Normative References
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
RFC2535, March 1999.
[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC2946,
September, 2000.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC2406, November 1998.
[GSS] Linn, J., "Generic Security Services Application Program
Interface Version 2, Update 1", RFC2743, January 2000.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "HyperText
Transfer Protocol", RFC2616, June 1999.
[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC2818, May 2000.
[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC2403, November 1998.
KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC1510, September 1993.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", STD 61, RFC2289, February 1998.
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC2522, March 1999.
[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 "Public Key Infrastructure Certificate and
Certificate Restoration List (CRL) Profile", RFC3280,
April 2002.
[RFC-2223] Postel J. and J. Reynolds, "Instructions to RFCAuthors",
RFC2223, October 1997.
[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
BCP 30, RFC2505, February 1999.
[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC2821,
April 2001.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC2222, October 1997.
[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B. and T. Ylonen, "SPKI Certificate Theory", RFC2693,
September 1999.
[SSH] Ylonen, T., "SSH - Secure Login Connections Over the
Internet", 6th USENIX Security Symposium, p. 37-42, July
1996.
[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication",
RFC2554, March 1999.
[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC3207, February 2002.
[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText
Transfer Protocol", RFC2660, August 1999.
[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message
Specification", RFC2633, June 1999.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC854, May 1983.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC2246, January 1999.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D. and J.
Mikkelsen, "Transport Layer Security (TLS) Extensions",
RFC3546, May 2003.
[TCPSYN] "TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory
CA-1996-21, 19 September 1996, CERT.
http://www.cert.org/advisories/CA-1996-21.html
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within