Request for Comments: 3631 J. Schiller, Ed.
Category: Informational C. Kaufman, Ed.
Internet Architecture Board
December 2003
Security Mechanisms for the Internet
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Security must be built into Internet Protocols for those protocols to
offer their services securely. Many security problems can be traced
to improper implementations. However, even a proper implementation
will have security problems if the fundamental protocol is itself
exploitable. Exactly how security should be implemented in a
protocol will vary, because of the structure of the protocol itself.
However, there are many protocols for which standard Internet
security mechanisms, already developed, may be applicable. The
precise one that is appropriate in any given situation can vary. We
review a number of different choices, explaining the properties of
each.
1. Introduction
Internet Security compromises can be divided into several classes,
ranging from Denial of Service to Host Compromise. Denial of Service
attacks based on sheer volume of traffic are beyond the scope of this
document, though they are the subject of much ongoing discussion and
research. It is important to note that many such attacks are made
more difficult by good security practices. Host Compromise (most
commonly caused by undetected Buffer Overflows) represent flaws in
individual implementations rather than flaws in protocols.
Nevertheless, carefully designed protocols can make such flaws less
likely to occur and harder to exploit.
However, there are security compromises that are facilitated by the
very protocols that are in use on the Internet. If a security
problem is inherent in a protocol, no manner of implementation will
be able to prevent the problem.
It is therefore vitally important that protocols developed for the
Internet provide this fundamental security.
Exactly how a protocol should be secured depends on the protocol
itself as well as the security needs of the protocol. However, we
have developed a number of standard security mechanisms in the IETF.
In many cases appropriate application of these mechanisms can provide
the necessary security for a protocol.
A number of possible mechanisms can be used to provide security on
the Internet. Which one should be selected depends on many different
factors. We attempt here to provide guidance, spelling out the
factors and the currently-standardized (or about-to-be-standardized)
solutions, as discussed at the IAB Security Architecture Workshop
[RFC2316].
Security, however, is an art, not a science. Attempting to follow a
recipe blindly can lead to disaster. As always, good taste in
protocol design should be exercised.
Finally, security mechanisms are not magic pixie dust that can be
sprinkled over completed protocols. It is rare that security can be
bolted on later. Good designs -- that is, secure, clean, and
efficient designs -- occur when the security mechanisms are crafted
along with the protocol. No conceivable exercise in cryptography can
secure a protocol with flawed semantic assumptions.
2. Decision Factors
2.1. Threat Model
The most important factor in choosing a security mechanism is the
threat model. That is, who may be expected to attack what resource,
using what sorts of mechanisms? A low-value target, such as a Web
site that offers public information only, may not merit much
protection. Conversely, a resource that if compromised could expose
significant parts of the Internet infrastructure, say, a major
backbone router or high-level Domain Name Server, should be protected
by very strong mechanisms. The value of a target to an attacker
depends on the purpose of the attack. If the purpose is to access
sensitive information, all systems that handle this information or
mediate access to it are valuable. If the purpose is to wreak havoc,
systems on which large parts of the Internet depend are exceedingly
valuable. Even if only public information is posted on a web site,
changing its contents can cause embarrassment to its owner and could
result in substantial damage. It is difficult when designing a
protocol to predict what uses that protocol will someday have.
All Internet connected systems require a minimum amount of
protection. Starting in 2000 and continuing to the present, we have
witnessed the advent of a new type of Internet security attack: an
Internet "worm" program that seeks out and automatically attacks
systems that are vulnerable to compromise via a number of attacks
built into the worm program itself. These worm programs can
compromise literally thousands of systems within a very short period
of time. Note that the first Internet Worm was the "Morris" worm of
1988. However, it was not followed up with similar programs for over
12 years!
As of the writing of this document, all of these worms have taken
advantage of programming errors in the implementation of otherwise
reasonably secure protocols. However, it is not hard to envision an
attack that targets a fundamental security flaw in a widely deployed
protocol. It is therefore imperative that we strive to minimize such
flaws in the protocols we design.
The value of a target to an attacker may depend on where it is
located. A network monitoring station that is physically on a
backbone cable is a major target, since it could easily be turned
into an eavesdropping station. The same machine, if located on a
stub net and used for word processing, would be of much less use to a
sophisticated attacker, and hence would be at significantly less
risk.
One must also consider what sorts of attacks may be expected. At a
minimum, eavesdropping must be seen as a serious threat; there have
been very many such incidents since at least 1993. Often, active
attacks, that is, attacks that involve insertion or deletion of
packets by the attacker, are a risk as well. It is worth noting that
such attacks can be launched with off-the-shelf tools, and have in
fact been observed "in the wild". Of particular interest is a form
of attack called "session hijacking", where someone on a link between
the two communicating parties wait for authentication to complete and
then impersonate one of the parties and continue the connection with
the other.
One of the most important tools available to us for securing
protocols is cryptography. Cryptography permits us to apply various
kinds of protection to data as it traverses the network, without
having to depend on any particular security properties of the network
itself. This is important because the Internet, by its distributed
management and control, cannot be considered a trustworthy media in
and of itself. Its security derives from the mechanisms that we
build into the protocols themselves, independent of the underlying
media or network operators.
Finally, of course, there is the cost to the defender of using
cryptography. This cost is dropping rapidly; Moore’s Law, plus the
easy availability of cryptographic components and toolkits, makes it
relatively easy to use strong protective techniques. Although there
are exceptions, public key operations are still expensive, perhaps
prohibitively so if the cost of each public-key operation is spread
over too few transactions, careful engineering design can generally
let us spread this cost over many transactions.
In general, the default today should be to use the strongest
cryptography available in any protocol. Strong cryptography often
costs no more, and sometimes less, then weaker cryptography. The
actual performance cost of an algorithm is often unrelated to the
security it provides. Depending on the hardware available,
cryptography can be performed at very high rates (1+Gbps), and even
in software its performance impact is shrinking over time.
2.2. A Word about Mandatory Mechanisms
We have evolved in the IETF the notion of "mandatory to implement"
mechanisms. This philosophy evolves from our primary desire to
ensure interoperability between different implementations of a
protocol. If a protocol offers many options for how to perform a
particular task, but fails to provide for at least one that all must
implement, it may be possible that multiple, non-interoperable
implementations may result. This is the consequence of the selection
of non-overlapping mechanisms being deployed in the different
implementations.
Although a given protocol may make use of only one or a few security
mechanisms, these mechanisms themselves often can make use of several
cryptographic systems. The various cryptographic systems vary in
strength and performance. However, in many protocols we need to
specify a "mandatory to implement" to ensure that any two
implementations will eventually be able to negotiate a common
cryptographic system between them.
There are some protocols that were originally designed to be run in a
very limited domain. It is often argued that the domain of
implementation for a particular protocol is sufficiently well defined
and secure that the protocol itself need not provide any security
mechanisms.
History has shown this argument to be wrong. Inevitably, successful
protocols - even if developed for limited use - wind up used in a
broader environment, where the initial security assumptions do not
hold.
To solve this problem, the IETF requires that *ALL* protocols provide
appropriate security mechanisms, even when their domain of
application is at first believed to be very limited.
It is important to understand that mandatory mechanisms are mandatory
to *implement*. It is not necessarily mandatory that end-users
actually use these mechanisms. If an end-user knows that they are
deploying a protocol over a "secure" network, then they may choose to
disable security mechanisms that they believe are adding insufficient
value as compared to their performance cost. (We are generally
skeptical of the wisdom of disabling strong security even then, but
that is beyond the scope of this document.)
Insisting that certain mechanisms are mandatory to implement means
that those end-users who need the protocol provided by the security
mechanism have it available when needed. Particularly with security
mechanisms, just because a mechanism is mandatory to implement does
not imply that it should be the default mechanism or that it may not
be disabled by configuration. If a mandatory to implement algorithm
is old and weak, it is better to disable it when a stronger algorithm
is available.
2.3. Granularity of Protection
Some security mechanisms can protect an entire network. While this
economizes on hardware, it can leave the interior of such networks
open to attacks from the inside. Other mechanisms can provide
protection down to the individual user of a timeshared machine,
though perhaps at risk of user impersonation if the machine has been
compromised.
When assessing the desired granularity of protection, protocol
designers should take into account likely usage patterns,
implementation layers (see below), and deployability. If a protocol
is likely to be used only from within a secure cluster of machines
(say, a Network Operations Center), subnet granularity may be
appropriate. By contrast, a security mechanism peculiar to a single
application is best embedded in that application, rather than inside
TCP; otherwise, deployment will be very difficult.
2.4. Implementation Layer
Security mechanisms can be located at any layer. In general, putting
a mechanism at a lower layer protects a wider variety of higher-layer
protocols, but may not be able to protect them as well. A link-layer
encryptor can protect not just IP, but even ARP packets. However,
its reach is just that one link. Conversely, a signed email message
is protected even if sent through many store-and-forward mail
gateways, can identify the actual sender, and the signature can be
verified long after the message is delivered. However, only that one
type of message is protected. Messages of similar formats, such as
some Netnews postings, are not protected unless the mechanism is
specifically adapted and then implemented in the news-handling
programs.
3. Standard Security Mechanisms
3.1. One-Time Passwords
One-time password schemes, such as that described in [RFC2289], are
very much stronger than conventional passwords. The host need not
store a copy of the user’s password, nor is it ever transmitted over
the network. However, there are some risks. Since the transmitted
string is derived from a user-typed password, guessing attacks may
still be feasible. (Indeed, a program to launch just this attack is
readily available.) Furthermore, the user’s ability to login
necessarily expires after a predetermined number of uses. While in
many cases this is a feature, an implementation most likely needs to
provide a way to reinitialize the authentication database, without
requiring that the new password be sent in the clear across the
network.
There are commercial hardware authentication tokens. Apart from the
session hijacking issue, support for such tokens (especially
challenge/response tokens, where the server sends a different random
number for each authentication attempt) may require extra protocol
messages.
3.2. HMAC
HMAC [RFC2104] is the preferred shared-secret authentication
technique. If both sides know the same secret key, HMAC can be used
to authenticate any arbitrary message. This includes random
challenges, which means that HMAC can be adapted to prevent replays
of old sessions.
An unfortunate disadvantage of using HMAC for connection
authentication is that the secret must be known in the clear by both
parties, making this undesirable when keys are long-lived.
When suitable, HMAC should be used in preference to older techniques,
notably keyed hash functions. Simple keyed hashes based on MD5
[RFC1321], such as that used in the BGP session security mechanism
[RFC2385], are especially to be avoided in new protocols, given the
hints of weakness in MD5.
HMAC can be implemented using any secure hash function, including MD5
and SHA-1 [RFC3174]. SHA-1 is preferable for new protocols because
it is more frequently used for this purpose and may be more secure.
It is important to understand that an HMAC-based mechanism needs to
be employed on every protocol data unit (aka packet). It is a
mistake to use an HMAC-based system to authenticate the beginning of
a TCP session and then send all remaining data without any
protection.
Attack programs exist that permit a TCP session to be stolen. An
attacker merely needs to use such a tool to steal a session after the
HMAC step is performed.
3.3. IPsec
IPsec [RFC2401],[RFC2402],[RFC2406],[RFC2407],[RFC2411] is the
generic IP-layer encryption and authentication protocol. As such, it
protects all upper layers, including both TCP and UDP. Its normal
granularity of protection is host-to-host, host-to-gateway, and
gateway-to-gateway. The specification does permit user-granularity
protection, but this is comparatively rare. As such, IPsec is
currently inappropriate when host-granularity is too coarse.
Because IPsec is installed at the IP layer, it is rather intrusive to
the networking code. Implementing it generally requires either new
hardware or a new protocol stack. On the other hand, it is fairly
transparent to applications. Applications running over IPsec can
have improved security without changing their protocols at all. But
at least until IPsec is more widely deployed, most applications
should not assume they are running atop IPsec as an alternative to
specifying their own security mechanisms. Most modern operating
systems have IPsec available; most routers do not, at least for the
control path. An application using TLS is more likely to be able to
assert application-specific to take advantage of its authentication.
The key management for IPsec can use either certificates or shared
secrets. For all the obvious reasons, certificates are preferred;
however, they may present more of a headache for the system manager.
There is strong potential for conflict between IPsec and NAT
[RFC2993]. NAT does not easily coexist with any protocol containing
embedded IP address; with IPsec, every packet, for every protocol,
contains such addresses, if only in the headers. The conflict can
sometimes be avoided by using tunnel mode, but that is not always an
appropriate choice for other reasons. There is ongoing work to make
IPsec pass through NAT more easily [NATIKE].
Most current IPsec usage is for virtual private networks. Assuming
that the other constraints are met, IPsec is the security protocol of
choice for VPN-like situations, including the remote access scenario
where a single machine tunnels back into its home network over the
internet using IPsec.
3.4. TLS
TLS [RFC2246] provides an encrypted, authenticated channel that runs
on top of TCP. While TLS was originally designed for use by Web
browsers, it is by no means restricted to such. In general, though,
each application that wishes to use TLS will need to be converted
individually.
Generally, the server side is always authenticated by a certificate.
Clients may possess certificates, too, providing mutual
authentication, though this is rarely deployed. It’s an unfortunate
reality that even server side authentication it not as secure in
practice as the cryptography would imply because most implementations
allow users to ignore authentication failures (by clicking OK to a
warning) and most users routinely do so [Bell98]. Designers should
thus be wary of demanding plaintext passwords, even over TLS-
protected connections. (This requirement can be relaxed if it is
likely that implementations will be able to verify the authenticity
and authorization of the server’s certificate.)
Although application modification is generally required to make use
of TLS, there exist toolkits, both free and commercial, that provide
implementations. These are designed to be incorporated into the
application’s code. An application using TLS is more likely to be
able to assert application specific certificate policies than one
using IPsec.
3.5. SASL
SASL [RFC2222] is a framework for negotiating an authentication and
encryption mechanism to be used over a TCP stream. As such, its
security properties are those of the negotiated mechanism.
Specifically, unless the negotiated mechanism authenticates all of
the subsequent messages or underlying protection protocol such as TLS
is used, TCP connections are vulnerable to session stealing.
If you need to use TLS (or IPSec) under SASL, why bother with SASL in
the first place? Why not simply use the authentication facilities of
TLS and be done with it?
The answer here is subtle. TLS makes extensive use of certificates
for authentication. As commonly deployed, only servers have
certificates, whereas clients go unauthenticated (at least by the TLS
processing itself).
SASL permits the use of more traditional client authentication
technologies, such as passwords (one-time or otherwise). A powerful
combination is TLS for underlying protection and authentication of
the server, and a SASL-based system for authenticating clients. Care
must be taken to avoid man-in-the-middle vulnerabilities when
different authentication techniques are used in different directions.
3.6. GSS-API
GSS-API [RFC2744] provides a framework for applications to use when
they require authentication, integrity, and/or confidentiality.
Unlike SASL, GSS-API can be used easily with UDP-based applications.
It provides for the creation of opaque authentication tokens (aka
chunks of memory) which may be embedded in a protocol’s data units.
Note that the security of GSS-API-protected protocols depends on the
underlying security mechanism; this must be evaluated independently.
Similar considerations apply to interoperability, of course.
3.7. DNSSEC
DNSSEC [RFC2535] digitally signs DNS records. It is an essential
tool for protecting against DNS cache contamination attacks [Bell95];
these in turn can be used to defeat name-based authentication and to
redirect traffic to or past an attacker. The latter makes DNSSEC an
essential component of some other security mechanisms, notably IPsec.
Although not widely deployed on the Internet at the time of the
writing of this document, it offers the potential to provide a secure
mechanism for mapping domain names to IP protocol addresses. It may
also be used to securely associate other information with a DNS name.
This information may be as simple as a service that is supported on a
given node, or a key to be used with IPsec for negotiating a secure
session. Note that the concept of storing general purpose
application keys in the DNS has been deprecated [RFC3445], but
standardization of storing keys for particular applications - in
particular IPsec - is proceeding.
3.8. Security/Multipart
Security/Multiparts [RFC1847] are the preferred mechanism for
protecting email. More precisely, it is the MIME framework within
which encryption and/or digital signatures are embedded. Both S/MIME
and OpenPGP (see below) use Security/Multipart for their encoding.
Conforming mail readers can easily recognize and process the
cryptographic portions of the mail.
Security/Multiparts represents one form of "object security", where
the object of interest to the end user is protected, independent of
transport mechanism, intermediate storage, etc. Currently, there is
no general form of object protection available in the Internet.
For a good example of using S/MIME outside the context of email, see
Session Initiation Protocol [RFC 3261].
3.9. Digital Signatures
One of the strongest forms of challenge/response authentication is
based on digital signatures. Using public key cryptography is
preferable to schemes based on secret key ciphers because no server
needs a copy of the client’s secret. Rather, the client has a
private key; servers have the corresponding public key.
Using digital signatures properly is tricky. A client should never
sign the exact challenge sent to it, since there are several subtle
number-theoretic attacks that can be launched in such situations.
The Digital Signature Standard [DSS] and RSA [RSA] are both good
choices; each has its advantages. Signing with DSA requires the use
of good random numbers [RFC1750]. If the enemy can recover the
random number used for any given signature, or if you use the same
random number for two different documents, your private key can be
recovered. DSS has much better performance than RSA for generating
new private keys, and somewhat better performance generating
signatures, while RSA has much better performance for verifying
signatures.
3.10. OpenPGP and S/MIME
Digital signatures can be used to build "object security"
applications which can be used to protect data in store and forward
protocols such as electronic mail.
At this writing, two different secure mail protocols, OpenPGP
[OpenPGP] and S/MIME [S/MIME], have been proposed to replace PEM
[PEM]. It is not clear which, if either, will succeed. While
specified for use with secure mail, both can be adapted to protect
data carried by other protocols. Both use certificates to identify
users; both can provide secrecy and authentication of mail messages;
however, the certificate formats are very different. Historically,
the difference between PGP-based mail and S/MIME-based mail has been
the style of certificate chaining. In S/MIME, users possess X.509
certificates; the certification graph is a tree with a very small
number of roots. By contrast, PGP uses the so-called "web of trust",
where any user can sign anyone else’s certificate. This
certification graph is really an arbitrary graph or set of graphs.