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.
AbstractSecurity 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.
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.
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.
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.
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. 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. 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. 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.
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. 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. 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. 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]. 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.
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.
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. 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.
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. 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].
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. 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.
[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.
[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.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.