Internet DRAFT - draft-ietf-iab-secmech
draft-ietf-iab-secmech
Network Working Group Steven M. Bellovin
Internet Draft AT&T Labs Research
Expiration Date: December 1999 June 1999
Security Mechanisms for the Internet
draft-ietf-iab-secmech-01.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
Many different mechanisms can be used to provide security for
protocols. The precise one that is appropriate in any given
situation can vary. We review a number of different choices,
explaining the properties of each.
Bellovin [Page 1]
Internet Draft draft-iab-secmech-01.txt June 1999
3. Introduction
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.
4. Decision Factors
4.1. Threat Model
The most important factor in chosing 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 "charges" demographic 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 nameserver--should be protected by very
strong mechanisms.
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 at little 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 too many such incidents since at least 1993. In many
circumstances, active attacks--that is, attacks that involve
insertion or deletion of packets by the attacker--are a risk as well.
Finally, of course, there is the cost to the defender of using
cryptography. This cost is dropping rapidly; Moore's Law, plus the
Bellovin [Page 2]
Internet Draft draft-iab-secmech-01.txt June 1999
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--the default today should be to use the
strongest cryptography available.
4.2. 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 NOC), 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.
4.3. 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. The usual tradeoff is reach; lower-layer protocols
terminate sooner. Thus, 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 across
many store-and-forward mail gateways; 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.
Bellovin [Page 3]
Internet Draft draft-iab-secmech-01.txt June 1999
5. Standard Security Mechanisms
5.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 login inherently expires
after 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.
5.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 specifically includes
random challenges, which means that HMAC is suitable for logins.
The disadvantage, of course, is that the secret must be known in the
clear by both parties. In many situations, this is undesirable.
When suitable, HMAC should be used in preference to older techniques,
notably keyed hash functions. Keyed hashes based on MD5 [RFC1321]
are especially to be avoided, given the hints of weakness in MD5.
5.3. IPSEC
IPSEC [longlist] 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.
Because IPSEC is installed at the IP layer, it is rather intrusive.
Implementing it generally requires either new hardware or a new
protocol stack. This makes it a poor choice for individual
applications, at least until IPSEC is more widely deployed.
Bellovin [Page 4]
Internet Draft draft-iab-secmech-01.txt June 1999
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
[Hain99]. NAT does not easily co-exist 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.
5.4. TLS
TLS provides an encrypted, authenticated channel that runs on top of
TCP. While TLS was primarily intended 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 bilateral
authentication. The reality, though, is that for most practical Web
use, there is no authentication, since users do not check
certificates [Bell98]. Designers should thus be wary of demanding
plaintext passwords, even over TLS-protected connections.
5.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.
5.6. GSS-API GSS-API [RFCGSSAPI] 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.
5.7. DNSSEC
DNSSEC [RFC2535] digitally signs DNS records. It is an essential
tool for protecting against cache contamination attacks; 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.
Bellovin [Page 5]
Internet Draft draft-iab-secmech-01.txt June 1999
5.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 used. 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.
5.9. OpenPGP and S/MIME
At this writing, two different secure mail protocols, OpenPGP and
S/MIME, have been proposed to replace PEM. It is not clear which, if
either, will succeed. Both use certificates to identify users; both
can provide secrecy and authentication of mail messages; however, the
certficate 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. The certification graph really
is 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.
5.10. Digital Signatures
One of the strongest forms of challenge/response authentication is
based on digital signatures. It is preferable to schemes based on
ordinary ciphers because the server end does not need a copy of the
client's secret. Rather, the client has a private key; the server
has the corresponding secret key.
Using digital signatures properly is tricky. A client should never
sign the exact challenge sent to it, since there are several subtle
Bellovin [Page 6]
Internet Draft draft-iab-secmech-01.txt June 1999
number-theoretic attacks that can be launched in such situations.
The Digital Signature Standard [DSS] is a good choice; however,
signing requires the use of good random numbers [RFC1750]. If the
enemy can recover the random number used for any given signature,
your private key can be recovered.
5.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
are protocols that are deliberately passed through the firewall,
links that are tunneled through, or direct external connections from
nominally-inside hosts, weaken the protection. It should be noted
that this phenomenon can vitiate one oft-touted advantage of
firewalls, that they hide the existence of internal hosts from
outside eyes. Given the amount of leakage, 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 [Freed97]. 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.
Bellovin [Page 7]
Internet Draft draft-iab-secmech-01.txt June 1999
6. Insecurity Mechanisms
Some common security mechanisms are part of the problem rather than
part of the solution.
6.1. Plaintext Passowrds
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.
6.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 and/or 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 if you restrict
address-based authentication to machines on that network, you are
probably safe. But these conditions are rarely met.
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.
Bellovin [Page 8]
Internet Draft draft-iab-secmech-01.txt June 1999
6.3. Name-Based Authentication
Name-based authentication has all of the problems of address-based
authentication and adds new ones: attacks on the DNS. 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
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.
7. 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 have
their 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.
8. 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.
9. References
[RFC2316] "Report of the IAB Security Architecture Workshop". S.
Bellovin. April 1998.
[RFC2289] "A One-Time Password System". N. Haller, C. Metz, P.
Nesser, M. Straw. February 1998.
[RFC2104] "HMAC: Keyed-Hashing for Message Authentication". H.
Krawczyk, M. Bellare, R. Canetti. February 1997.
[RFC1321] "The MD5 Message-Digest Algorithm". R. Rivest. April 1992.
[RFC2401] "Security Architecture for the Internet Protocol". S. Kent,
R. Atkinson. November 1998.
[RFC2411] "IP Security Document Roadmap". R. Thayer, N. Doraswamy, R.
Glenn. November 1998.
Bellovin [Page 9]
Internet Draft draft-iab-secmech-01.txt June 1999
[Hain99] "Architectural Implications of NAT". T. Hain. April 1999.
Work in progress.
[Bell98] "Cryptography and the Internet", S.M. Bellovin, in
Proceedings of CRYPTO '98, August 1998.
[RFC2222] "Simple Authentication and Security Layer (SASL)". J.
Myers. October 1997.
[RFC2535] "Domain Name System Security Extensions". D. Eastlake.
March 1999.
[RFC1847] "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted". J. Galvin, S. Murphy, S. Crocker & N. Freed.
October 1995.
[DSS] "Digital Signature Standard". NIST. May 1994. FIPS 186.
[RFC1750] "Randomness Recommendations for Security". D. Eastlake,
3rd, S. Crocker & J. Schiller. December 1994.
[Freed97] "An Internet Firewall Transparency Requirement". N. Freed
and K. Carosso. December 1997. Work in progress.
[MT79] "UNIX Password Security", R.H. Morris and K. Thompson,
Communications of the ACM, November 1979.
10. Author Information
Steven M. Bellovin
AT&T Labs Research
Shannon Laboratory
180 Park Avenue
Florham Park, NJ 07974
Phone: +1 973-360-8656
email: smb@research.att.com
Bellovin [Page 10]
