doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc3631.txt b/doc/rfc/rfc3631.txt
new file mode 100644
index 0000000..2e1d1ca
--- /dev/null
+++ b/doc/rfc/rfc3631.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                   S. Bellovin, Ed.
+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.
+
+
+
+
+
+
+Bellovin, et al.             Informational                      [Page 1]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   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
+
+
+
+Bellovin, et al.             Informational                      [Page 2]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   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
+
+
+
+Bellovin, et al.             Informational                      [Page 3]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   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.
+
+
+
+
+Bellovin, et al.             Informational                      [Page 4]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   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.
+
+
+
+
+
+
+
+Bellovin, et al.             Informational                      [Page 5]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+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.
+
+
+
+
+
+
+Bellovin, et al.             Informational                      [Page 6]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   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.
+
+
+
+
+
+
+Bellovin, et al.             Informational                      [Page 7]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   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.
+
+
+
+
+
+
+
+Bellovin, et al.             Informational                      [Page 8]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+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.
+
+
+
+Bellovin, et al.             Informational                      [Page 9]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   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.
+
+
+
+
+
+
+Bellovin, et al.             Informational                     [Page 10]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+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.
+
+   With any certificate scheme, trust depends on two primary
+   characteristics.  First, it must start from a known-reliable source,
+   either an X.509 root, or someone highly trusted by the verifier,
+   often him or herself.  Second, the chain of signatures must be
+   reliable.  That is, each node in the certification graph is crucial;
+   if it is dishonest or has been compromised, any certificates it has
+   vouched for cannot be trusted.  All other factors being equal (and
+   they rarely are), shorter chains are preferable.
+
+   Some of the differences reflect a tension between two philosophical
+   positions represented by these technologies.  Others resulted from
+   having separate design teams.
+
+   S/MIME is designed to be "fool proof".  That is, very little end-user
+   configuration is required. Specifically, end-users do not need to be
+   aware of trust relationships, etc.  The idea is that if an S/MIME
+   client says, "This signature is valid", the user should be able to
+   "trust" that statement at face value without needing to understand
+   the underlying implications.
+
+   To achieve this, S/MIME is typically based on a limited number of
+   "root" Certifying Authorities (CAs).  The goal is to build a global
+   trusted certificate infrastructure.
+
+   The down side to this approach is that it requires a deployed public
+   key infrastructure before it will work.  Two end-users may not be
+   able to simply obtain S/MIME-capable software and begin communicating
+   securely.  This is not a limitation of the protocol, but a typical
+
+
+
+Bellovin, et al.             Informational                     [Page 11]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   configuration restriction for commonly available software.  One or
+   both of them may need to obtain a certificate from a mutually trusted
+   CA; furthermore, that CA must already be trusted by their mail
+   handling software.  This process may involve cost and legal
+   obligations.  This ultimately results in the technology being harder
+   to deploy, particularly in an environment where end-users do not
+   necessarily appreciate the value received for the hassle incurred.
+
+   The PGP "web of trust" approach has the advantage that two end-users
+   can just obtain PGP software and immediately begin to communicate
+   securely.  No infrastructure is required and no fees and legal
+   agreements need to be signed to proceed.  As such PGP appeals to
+   people who need to establish ad-hoc security associations.
+
+   The down side to PGP is that it requires end-users to have an
+   understanding of the underlying security technology in order to make
+   effective use of it.  Specifically it is fairly easy to fool a naive
+   users to accept a "signed" message that is in fact a forgery.
+
+   To date PGP has found great acceptance between security-aware
+   individuals who have a need for secure e-mail in an environment
+   devoid of the necessary global infrastructure.
+
+   By contrast, S/MIME works well in a corporate setting where a secure
+   internal CA system can be deployed.  It does not require a lot of
+   end-user security knowledge.  S/MIME can be used between institutions
+   by carefully setting up cross certification, but this is harder to do
+   than it seems.
+
+   As of this writing a global certificate infrastructure continues to
+   elude us.  Questions about a suitable business model, as well as
+   privacy considerations, may prevent one from ever emerging.
+
+3.11.  Firewalls and Topology
+
+   Firewalls are a topological defense mechanism.  That is, they rely on
+   a well-defined boundary between the good "inside" and the bad
+   "outside" of some domain, with the firewall mediating the passage of
+   information.  While firewalls can be very valuable if employed
+   properly, there are limits to their ability to protect a network.
+
+   The first limitation, of course, is that firewalls cannot protect
+   against inside attacks.  While the actual incidence rate of such
+   attacks is not known (and is probably unknowable), there is no doubt
+   that it is substantial, and arguably constitutes a majority of
+   security problems.  More generally, given that firewalls require a
+   well-delimited boundary, to the extent that such a boundary does not
+   exist, firewalls do not help.  Any external connections, whether they
+
+
+
+Bellovin, et al.             Informational                     [Page 12]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   are protocols that are deliberately passed through the firewall,
+   links that are tunneled through, unprotected wireless LANs, or direct
+   external connections from nominally-inside hosts, weaken the
+   protection.  Firewalls tend to become less effective over time as
+   users tunnel protocols through them and may have inadequate security
+   on the tunnel endpoints.  If the tunnels are encrypted, there is no
+   way for the firewall to censor them.  An oft-cited advantage of
+   firewalls is that they hide the existence of internal hosts from
+   outside eyes.  Given the amount of leakage, however, the likelihood
+   of successfully hiding machines is rather low.
+
+   In a more subtle vein, firewalls hurt the end-to-end model of the
+   Internet and its protocols.  Indeed, not all protocols can be passed
+   safely or easily through firewalls.  Sites that rely on firewalls for
+   security may find themselves cut off from new and useful aspects of
+   the Internet.
+
+   Firewalls work best when they are used as one element of a total
+   security structure.  For example, a strict firewall may be used to
+   separate an exposed Web server from a back-end database, with the
+   only opening the communication channel between the two.  Similarly, a
+   firewall that permitted only encrypted tunnel traffic could be used
+   to secure a piece of a VPN.  On the other hand, in that case the
+   other end of the VPN would need to be equally secured.
+
+3.12.  Kerberos
+
+   Kerberos [RFC1510] provides a mechanism for two entities to
+   authenticate each other and exchange keying material.  On the client
+   side, an application obtains a Kerberos "ticket" and "authenticator".
+   These items, which should be considered opaque data, are then
+   communicated from client to server.  The server can then verify their
+   authenticity.  Both sides may then ask the Kerberos software to
+   provide them with a session key which can be used to protect or
+   encrypt data.
+
+   Kerberos may be used by itself in a protocol.  However, it is also
+   available as a mechanism under SASL and GSSAPI.  It has some known
+   vulnerabilities [KRBATTACK] [KRBLIM] [KRB4WEAK], but it can be used
+   securely.
+
+3.13.  SSH
+
+   SSH provides a secure connection between client and server.  It
+   operates very much like TLS; however, it is optimized as a protocol
+   for remote connections on terminal-like devices.  One of its more
+   innovative features is its support for "tunneling" other protocols
+   over the SSH-protected TCP connection.  This feature has permitted
+
+
+
+Bellovin, et al.             Informational                     [Page 13]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   knowledgeable security people to perform such actions as reading and
+   sending e-mail or news via insecure servers over an insecure network.
+   It is not a substitute for a true VPN, but it can often be used in
+   place of one.
+
+4.  Insecurity Mechanisms
+
+   Some common security mechanisms are part of the problem rather than
+   part of the solution.
+
+4.1.  Plaintext Passwords
+
+   Plaintext passwords are the most common security mechanism in use
+   today.  Unfortunately, they are also the weakest.  When not protected
+   by an encryption layer, they are completely unacceptable.  Even when
+   used with encryption, plaintext passwords are quite weak, since they
+   must be transmitted to the remote system.  If that system has been
+   compromised or if the encryption layer does not include effective
+   authentication of the server to the client, an enemy can collect the
+   passwords and possibly use them against other targets.
+
+   Another weakness arises because of common implementation techniques.
+   It is considered good form [MT79] for the host to store a one-way
+   hash of the users' passwords, rather than their plaintext form.
+   However, that may preclude migrating to stronger authentication
+   mechanisms, such as HMAC-based challenge/response.
+
+   The strongest attack against passwords, other than eavesdropping, is
+   password-guessing.  With a suitable program and dictionary (and these
+   are widely available), 20-30% of passwords can be guessed in most
+   environments [Klein90].
+
+4.2.  Address-Based Authentication
+
+   Another common security mechanism is address-based authentication. At
+   best, it can work in highly constrained environments.  If your
+   environment consists of a small number of machines, all tightly
+   administered, secure systems run by trusted users, and if the network
+   is guarded by a router that blocks source-routing and prevents
+   spoofing of your source addresses, and you know there are no wireless
+   bridges, and if you restrict address-based authentication to machines
+   on that network, you are probably safe.  But these conditions are
+   rarely met.
+
+
+
+
+
+
+
+
+Bellovin, et al.             Informational                     [Page 14]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   Among the threats are ARP-spoofing, abuse of local proxies,
+   renumbering, routing table corruption or attacks, DHCP, IP address
+   spoofing (a particular risk for UDP-based protocols), sequence number
+   guessing, and source-routed packets.  All of these can be quite
+   potent.
+
+4.3.  Name-Based Authentication
+
+   Name-based authentication has all of the problems of address-based
+   authentication and adds new ones: attacks on the DNS [Bell95] and
+   lack of a one to one mapping between addresses and names.  At a
+   minimum, a process that retrieves a host name from the DNS should
+   retrieve the corresponding address records and cross-check.
+   Techniques such as DNS cache contamination can often negate such
+   checks.
+
+   DNSSEC provides protection against this sort of attack.  However, it
+   does nothing to enhance the reliability of the underlying address.
+   Further, the technique generates a lot of false alarms.  These
+   lookups do not provide reliable information to a machine, though they
+   might be a useful debugging tool for humans and could be useful in
+   logs when trying to reconstruct how and attack took place.
+
+5.  Security Considerations
+
+   No security mechanisms are perfect.  If nothing else, any network-
+   based security mechanism can be thwarted by compromise of the
+   endpoints.  That said, each of the mechanisms described here has its
+   own limitations.  Any decision to adopt a given mechanism should
+   weigh all of the possible failure modes.  These in turn should be
+   weighed against the risks to the endpoint of a security failure.
+
+6.  IANA Considerations
+
+   There are no IANA considerations regarding this document.
+
+7.  Acknowledgements
+
+   Brian Carpenter, Tony Hain, and Marcus Leech made a number of useful
+   suggestions.  Much of the substance comes from the participants in
+   the IAB Security Architecture Workshop.
+
+
+
+
+
+
+
+
+
+
+Bellovin, et al.             Informational                     [Page 15]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+8.  Informative References
+
+   [Bell95]    "Using the Domain Name System for System Break-Ins".
+               Proc.  Fifth Usenix Security Conference, 1995.
+
+   [Bell98]    "Cryptography and the Internet", S.M. Bellovin, in
+               Proceedings of CRYPTO '98, August 1998.
+
+   [DSS]       "Digital Signature Standard".  NIST.  May 1994.  FIPS
+               186.
+
+   [Klein90]   "Foiling the Cracker: A Survey of, and Implications to,
+               Password Security". D. Klein. Usenix UNIX Security
+               Workshop, August 1990.
+
+   [KRBATTACK] "A Real-World Analysis of Kerberos Password Security".
+               T. Wu. Network and Distributed System Security Symposium
+               (NDSS '99).  January 1999.
+
+   [KRBLIM]    "Limitations of the Kerberos Authentication System".
+               Proceedings of the 1991 Winter USENIX Conference, 1991.
+
+   [KRB4WEAK]  "Misplaced trust: Kerberos 4 session keys".  Proceedings
+               of the Internet Society Network and Distributed Systems
+               Security Symposium, March 1997.
+
+   [MT79]      "UNIX Password Security", R.H. Morris and K.  Thompson,
+               Communications of the ACM. November 1979.
+
+   [NATIKE]    Kivinen, T., et al., "Negotiation of NAT-Traversal in the
+               IKE", Work in Progress, June 2002.
+
+   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+               April 1992.
+
+   [RFC1510]   Kohl, J. and C. Neuman, "The Kerberos Network
+               Authentication Service (V5)", RFC 1510, September 1993.
+
+   [RFC1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+               Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC1847]   Galvin, J., Murphy, S., Crocker, S. and N. Freed,
+               "Security Multiparts for MIME: Multipart/Signed and
+               Multipart/Encrypted", RFC 1847, October 1995.
+
+   [RFC2104]   Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
+               Hashing for Message Authentication", RFC 2104, February
+               1997.
+
+
+
+Bellovin, et al.             Informational                     [Page 16]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   [RFC2222]   Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+               RFC 2246, January 1999.
+
+   [RFC2289]   Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-
+               Time Password System", STD 61, RFC 2289, February 1998.
+
+   [RFC2316]   Bellovin, S., "Report of the IAB Security Architecture
+               Workshop", RFC 2316, April 1998.
+
+   [RFC2385]   Hefferman, A., "Protection of BGP Sessions via the TCP
+               MD5 Signature Option", RFC 2385, August 1998.
+
+   [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
+               Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2402]   Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+               2402, November 1998.
+
+   [RFC2406]   Kent, S. and R. Atkinson, "IP Encapsulating Security
+               Payload (ESP)", RFC 2406, November 1998.
+
+   [RFC2407]   Piper, D., "The Internet IP Security Domain of
+               Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [RFC2411]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
+               Document Roadmap", RFC 2411, November 1998.
+
+   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
+               RFC 2535, March 1999.
+
+   [RFC2744]   Wray, J., "Generic Security Service API Version 2:  C-
+               bindings", RFC 2744, January 2000.
+
+   [RFC2993]   Hain, T., "Architectural Implications of NAT", RFC 2993,
+               November 2000.
+
+   [RFC3174]   Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+               (SHA1)", RFC 3174, September 2001.
+
+   [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, R., Johnston,
+               A., Peterson, J., Sparks, R., Handley, M. and E.
+               Schooler, "SIP:  Session Initiation Protocol", RFC 3261,
+               June 2002.
+
+
+
+
+
+Bellovin, et al.             Informational                     [Page 17]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+   [RFC3445]   Massey, D. and S. Rose, "Limiting the Scope of the KEY
+               Resource Record (RR)", RFC 3445, December 2002.
+
+   [RSA]       Rivest, R., Shamir, A. and L. Adleman, "A Method for
+               Obtaining Digital Signatures and Public-Key
+               Cryptosystems", Communications of the ACM, February 1978.
+
+9.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin, et al.             Informational                     [Page 18]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+10.  Author Information
+
+   This document is a publication of the Internet Architecture Board.
+   Internet Architecture Board Members at the time this document was
+   completed were:
+
+   Bernard Aboba
+   Harald Alvestrand
+   Rob Austein
+   Leslie Daigle, Chair
+   Patrik Faltstrom
+   Sally Floyd
+   Jun-ichiro Itojun Hagino
+   Mark Handley
+   Geoff Huston
+   Charlie Kaufman
+   James Kempf
+   Eric Rescorla
+   Michael StJohns
+
+   Internet Architecture Board
+   EMail: iab@iab.org
+
+   Steven M. Bellovin, Editor
+   EMail: bellovin@acm.org
+
+   Jeffrey I. Schiller, Editor
+   EMail: jis@mit.edu
+
+   Charlie Kaufman, Editor
+   EMail: charliek@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin, et al.             Informational                     [Page 19]
+
+RFC 3631          Security Mechanisms for the Internet     December 2003
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin, et al.             Informational                     [Page 20]
+