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]