idnits 2.17.1 draft-iab-secmech-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2003) is 7743 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'OpenPGP' is mentioned on line 464, but not defined == Missing Reference: 'PEM' is mentioned on line 465, but not defined == Missing Reference: 'RFC1510' is mentioned on line 580, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 2316 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Downref: Normative reference to an Informational RFC: RFC 3174 -- Possible downref: Non-RFC (?) normative reference: ref. 'Hain99' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell98' ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) -- Possible downref: Non-RFC (?) normative reference: ref. 'MT79' -- Possible downref: Non-RFC (?) normative reference: ref. 'Klein90' Summary: 21 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steven M. Bellovin 3 Internet Draft AT&T Labs Research 4 Charlie Kaufman 5 IBM 6 Jeffrey I. Schiller 7 MIT 9 Expiration Date: July 2003 January 2003 11 Security Mechanisms for the Internet 13 draft-iab-secmech-02.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 Security must be built into Internet Protocols for those protocols to 39 offer their services securely. Many security problems can be traced 40 to improper implementations. However, even a proper implementation 41 will have security problems if the fundamental protocol is itself 42 exploitable. Exactly how security should be implemented in a 43 protocol will vary, because of the structure of the protocol itself. 44 However, there are many protocols for which standard Internet 45 security mechanisms, already developed, may be applicable. The 46 precise one that is appropriate in any given situation can vary. We 47 review a number of different choices, explaining the properties of 48 each. 50 3. Introduction 52 Internet Security compromises can be divided into several classes, 53 ranging from Denial of Service to Host Compromise. Denial of Service 54 attacks are beyond the scope of this document except to the extent 55 that they are made more difficult by good security practices. Host 56 Compromise (most commonly caused by undetected Buffer Overflows) 57 represent flaws in individual implementations rather than flaws in 58 protocols. Nevertheless, carefully designed protocols can make such 59 flaws less likely to occur and harder to exploit. 61 However there are security compromises that are facilitated by the 62 very protocols that are in use on the Internet. If a security problem 63 is inherent in a protocol, no manner of implementation will be able 64 to prevent the problem. 66 It is therefore vitally important that protocols developed for the 67 Internet provide this fundamental security. 69 Exactly how a protocol should be secured depends on the protocol 70 itself as well as the security needs of the protocol. However we have 71 developed a number of standard security mechanisms in the IETF. In 72 many cases appropriate application of these mechanisms can provide 73 the necessary security for a protocol. 75 A number of possible mechanisms can be used to provide security on 76 the Internet. Which one should be selected depends on many different 77 factors. We attempt here to provide guidance, spelling out the 78 factors and the currently-standardized (or about-to-be-standardized) 79 solutions, as discussed at the IAB Security Architecture Workshop 80 [RFC2316]. 82 Security, however, is an art, not a science. Attempting to follow a 83 recipe blindly can lead to disaster. As always, good taste in 84 protocol design should be exercised. 86 Finally, security mechanisms are not magic pixie dust that can be 87 sprinkled over completed protocols. It is rare that security can be 88 bolted on later. Good designs--that is, secure, clean, and efficient 89 designs--occur when the security mechanisms are crafted along with 90 the protocol. No conceivable exercise in cryptography can secure a 91 protocol with flawed semantic assumptions. 93 4. Decision Factors 95 4.1. Threat Model 97 The most important factor in choosing a security mechanism is the 98 threat model. That is, who may be expected to attack what resource, 99 using what sorts of mechanisms? A low-value target, such as a Web 100 site that offers public information only, may not merit much 101 protection. Conversely, a resource that if compromised could expose 102 significant parts of the Internet infrastructure--say, a major 103 backbone router or high-level Domain Name Server--should be protected 104 by very strong mechanisms. The value of a target to an attacker 105 depends on the purpose of the attack. If the purpose is to access 106 sensitive information, all systems that handle this information or 107 mediate access to it are valuable. If the purpose is to wreak havoc, 108 systmes on which large parts of the Internet depend are exceedingly 109 valuable. Even if only public information is posted on a web site, 110 changing its contents can cause embarassment to its owner and could 111 result in substantial damage. It is difficult when designing a 112 protocol to predict what uses that protocol will someday have. 114 All Internet connected systems require a minimum amount of 115 protection. Starting in 2000 and continuing to the present, we have 116 witnessed the advent of a new type of Internet security attack: an 117 Internet "worm" program that seeks out and automatically attacks 118 systems that are vulnerable to compromise via a number of attacks 119 built into the worm program itself. These worm programs can 120 compromise literally thousands of systems within a very short period 121 of time. 123 As of the writing of this document, all of these worms have taken 124 advantage of programming errors in the implementation of otherwise 125 reasonably secure protocols. However, it is not hard to envision an 126 attack that targets a fundamental security flaw in a widely deployed 127 protocol. It is therefore imperative that we strive to minimize such 128 flaws in the protocols we design. 130 [footnote: The first Internet Worm was the "Morris" worm of 1988. 131 However it was not followed up with similar programs for over 12 132 years!] 134 The value of a target to an attacker may depend on where it is 135 located. A network monitoring station that is physically on a 136 backbone cable is a major target, since it could easily be turned 137 into an eavesdropping station. The same machine, if located on a 138 stub net and used for word processing, would be of much less use to a 139 sophisticated attacker, and hence would be at significantly less 140 risk. 142 One must also consider what sorts of attacks may be expected. At a 143 minimum, eavesdropping must be seen as a serious threat; there have 144 been very many such incidents since at least 1993. Often, active 145 attacks--that is, attacks that involve insertion or deletion of 146 packets by the attacker--are a risk as well. It is worth noting that 147 such attacks can be launched with off-the-shelf tools, and have in 148 fact been observed "in the wild". Of particular interest is a form of 149 attack called "session hijacking", where someone on a link between 150 the two communicating parties wait for authentication to complete and 151 then impersonate one of the parties and continue the connection with 152 the other. 154 One of the most important tools available to us for securing 155 protocols is cryptography. Cryptography permits us to apply various 156 kinds of protection to data as it traverses the network, without 157 having to depend on any particular security properties of the network 158 itself. This is important because the Internet, by its distributed 159 management and control, cannot be considered a trustworthy media in 160 and of itself. Its security derives from the mechanisms that we build 161 into the protocols themselves, independent of the underlying media or 162 network operators. 164 Finally, of course, there is the cost to the defender of using 165 cryptography. This cost is dropping rapidly; Moore's Law, plus the 166 easy availability of cryptographic components and toolkits, makes it 167 relatively easy to use strong protective techniques. Although there 168 are exceptions--public key operations are still expensive, perhaps 169 prohibitively so if the cost of each public-key operation is spread 170 over too few transactions--careful engineering design can generally 171 let us spread this cost over many transactions. 173 In general, the default today should be to use the strongest 174 cryptography available in any protocol. Strong cryptography often 175 costs no more, and sometimes less, then weaker cryptography. The 176 actual performance cost of an algorithm is often unrelated to the 177 security it provides. 179 4.2. A word about Mandatory Mechanisms 181 We have evolved in the IETF the notion of "mandatory to implement" 182 mechanisms. This philosophy evolves from our primary desire to ensure 183 interoperability between different implementations of a protocol. If 184 a protocol offers many options for how to perform a particular task, 185 but fails to provide for at last one that all must implement, it may 186 be possible that multiple, non-interoperable implementations may 187 result. This is the consequence of the selection of non-overlapping 188 mechanisms being deployed in the different implementations. 190 Although a given protocol may make use of only one or a few security 191 mechanisms, these mechanisms themselves often can make use of several 192 cryptographic systems. The various cryptographic systems vary in 193 strength and performance. However, in many protocols we need to 194 specify a "mandatory to implement" to ensure that any two 195 implementations will eventually be able to negotiate a common 196 cryptographic system between them. 198 There are some protocols that were originally designed to be run in a 199 very limited domain. It is often argued that the domain of 200 implementation for a particular protocol is sufficiently well defined 201 and secure that the protocol itself need not provide any security 202 mechanisms. 204 History has shown this argument to be wrong. Inevitably, successful 205 protocols - even if developed for limited use - wind up used in a 206 broader environment, where the initial security assumptions do not 207 hold. 209 To solve this problem, the IETF requires that *ALL* protocols provide 210 appropriate security mechanisms, even when their domain of 211 application is at first believed to be very limited. 213 It is important to understand that mandatory mechanisms are mandatory 214 to *implement*. It is not necessarily mandatory that end-users 215 actually use these mechanisms. If an end-user knows that they are 216 deploying a protocol over a "secure" network, then they may choose to 217 disable security mechanisms that they believe are adding insufficient 218 value as compared to their performance cost. (We are generally 219 skeptical of the wisdom of disabling strong security even then, but 220 that is beyond the scope of this document.) 222 Insisting that certain mechanisms are mandatory to implement means 223 that those end-users who need the protocol provided by the security 224 mechanism have it available when needed. 226 4.3. Granularity of Protection 228 Some security mechanisms can protect an entire network. While this 229 economizes on hardware, it can leave the interior of such networks 230 open to attacks from the inside. Other mechanisms can provide 231 protection down to the individual user of a timeshared machine, 232 though perhaps at risk of user impersonation if the machine has been 233 compromised. 235 When assessing the desired granularity of protection, protocol 236 designers should take into account likely usage patterns, 237 implementation layers (see below), and deployability. If a protocol 238 is likely to be used only from within a secure cluster of machines 239 (say, a Network Operations Center), subnet granularity may be 240 appropriate. By contrast, a security mechanism peculiar to a single 241 application is best embedded in that application, rather than inside 242 TCP; otherwise, deployment will be very difficult. 244 4.4. Implementation Layer 246 Security mechanisms can be located at any layer. In general, putting 247 a mechanism at a lower layer protects a wider variety of higher-layer 248 protocols, but may not be able to protect them as well. A link-layer 249 encryptor can protect not just IP, but even ARP packets. However, 250 its reach is just that one link. Conversely, a signed email message 251 is protected even if sent through many store-and-forward mail 252 gateways, can identify the actual sender, and the signature can be 253 verified long after the message is delivered. However, only that one 254 type of message is protected. Messages of similar formats, such as 255 some Netnews postings, are not protected unless the mechanism is 256 specifically adapted and then implemented in the news-handling 257 programs. 259 5. Standard Security Mechanisms 261 5.1. One-Time Passwords 263 One-time password schemes, such as that described in [RFC2289], are 264 very much stronger than conventional passwords. The host need not 265 store a copy of the user's password, nor is it ever transmitted over 266 the network. However, there are some risks. Since the transmitted 267 string is derived from a user-typed password, guessing attacks may 268 still be feasible. (Indeed, a program to launch just this attack is 269 readily available.) Furthermore, the user's ability to login 270 necessarily expires after a predetermined number of uses. While in 271 many cases this is a feature, an implementation most likely needs to 272 provide a way to reinitialize the authentication database, without 273 requiring that the new password be sent in the clear across the 274 network. 276 There are commercial hardware authentication tokens. Apart from the 277 session hijacking issue, support for such tokens (especially 278 challenge/response tokens, where the server sends a different random 279 number for each authentication attempt) may require extra protocol 280 messages. 282 5.2. HMAC 284 HMAC [RFC2104] is the preferred shared-secret authentication 285 technique. If both sides know the same secret key, HMAC can be used 286 to authenticate any arbitrary message. This includes random 287 challenges, which means that HMAC can be adapted to prevent replays 288 of old sessions. 290 An unfortunate disadvantage of using HMAC for connection 291 authentication is that the secret must be known in the clear by both 292 parties, making this undesireable when keys are long-lived. 294 When suitable, HMAC should be used in preference to older techniques, 295 notably keyed hash functions. Simple keyed hashes based on MD5 296 [RFC1321], such as that used in the BGP session security mechanism 297 [RFC2385], are especially to be avoided in new protocols, given the 298 hints of weakness in MD5. 300 HMAC can be implemented using any secure hash function, including MD5 301 and SHA-1 [RFC3174]. SHA-1 is preferable for new protocols because 302 it is more frequently used for this purpose and may be more secure. 304 It is important to understand that an HMAC-based mechanism needs to 305 be employed on every protocol data unit (aka packet). It is a mistake 306 to use an HMAC-based system to authenticate the beginning of a TCP 307 session and then send all remaining data without any protection. 309 Attack programs exist that permit a TCP session to be stolen. An 310 attacker merely needs to use such a tool to steal a session after the 311 HMAC step is performed. 313 5.3. IPsec 315 IPsec [RFC2401],[RFC2402],[RFC2406],[RFC2407],[RFC2411] is the 316 generic IP-layer encryption and authentication protocol. As such, it 317 protects all upper layers, including both TCP and UDP. Its normal 318 granularity of protection is host-to-host, host-to-gateway, and 319 gateway-to-gateway. The specification does permit user-granularity 320 protection, but this is comparatively rare. As such, IPsec is 321 currently inappropriate when host-granularity is too coarse. 323 Because IPsec is installed at the IP layer, it is rather intrusive. 324 Implementing it generally requires either new hardware or a new 325 protocol stack. This makes it a poor choice for individual 326 applications, at least until IPsec is more widely deployed. Most 327 modern operating systems have IPsec available; most routers do not, 328 at least for the control path. 330 The key management for IPsec can use either certificates or shared 331 secrets. For all the obvious reasons, certificates are preferred; 332 however, they may present more of a headache for the system manager. 334 There is strong potential for conflict between IPsec and NAT 335 [Hain99]. NAT does not easily co-exist with any protocol containing 336 embedded IP address; with IPsec, every packet, for every protocol, 337 contains such addresses, if only in the headers. The conflict can 338 sometimes be avoided by using tunnel mode, but that is not always an 339 appropriate choice for other reasons. 341 Most current IPsec usage is for virtual private nets. Assuming that 342 the other constraints are met, IPsec is the security protocol of 343 choice for VPN-like situations. 345 5.4. TLS 347 TLS [RFC2246] provides an encrypted, authenticated channel that runs 348 on top of TCP. While TLS was originally designed for use by Web 349 browsers, it is by no means restricted to such. In general, though, 350 each application that wishes to use TLS will need to be converted 351 individually. 353 Generally, the server side is always authenticated by a certificate. 354 Clients may possess certificates, too, providing mutual 355 authentication, though this is rarely deployed. It's an unfortunate 356 reality that even server side authentication it not as secure in 357 practice as the cryptography would imply because most implementations 358 allow users to ignore authentication failures (by clicking OK to a 359 warning) and most users routinely do so [Bell98]. Designers should 360 thus be wary of demanding plaintext passwords, even over TLS- 361 protected connections. (This requirement can be relaxed if it is 362 likely that implementations will be able to verify the authenticity 363 and authorization of the server's certificate.) 365 Although application modification is generally required to make use 366 of TLS, there exist toolkits, both free and commercial, that provide 367 implementations. These are designed to be incorporated into the 368 application's code. 370 5.5. SASL 372 SASL [RFC2222] is a framework for negotiating an authentication and 373 encryption mechanism to be used over a TCP stream. As such, its 374 security properties are those of the negotiated mechanism. 375 Specifically, unless the negotiated mechanism authenticates all of 376 the subsequent messages or underlying protection protocol such as TLS 377 is used, TCP connections are vulnerable to session stealing. 379 If you need to use TLS (or IPSec) under SASL, why bother with SASL in 380 the first place? Why not simply use the authentication facilities of 381 TLS and be done with it? 383 The answer here is subtle. TLS makes extensive use of certificates 384 for authentication. As commonly deployed, only servers have 385 certificates, whereas clients go unauthenticated (at least by the TLS 386 processing itself). 388 SASL permits the use of more traditional client authentication 389 technologies, such as passwords (one-time or otherwise). A powerful 390 combination is TLS for underlying protection and authentication of 391 the server, and a SASL-based system for authenticating clients. 393 5.6. GSS-API 395 GSS-API [RFC2744] provides a framework for applications to use when 396 they require authentication, integrity, and/or confidentiality. 397 Unlike SASL, GSS-API can be used easily with UDP-based applications. 398 It provides for the creation of opaque authentication tokens (aka 399 chunks of memory) which may be embedded in a protocol's data units. 400 Note that the security of GSS-API-protected protocols depends on the 401 underlying security mechanism; this must be evaluated independently. 402 Similar considerations apply to interoperability, of course. 404 5.7. DNSSEC 406 DNSSEC [RFC2535] digitally signs DNS records. It is an essential 407 tool for protecting against DNS cache contamination attacks [Bell95]; 408 these in turn can be used to defeat name-based authentication and to 409 redirect traffic to or past an attacker. The latter makes DNSSEC an 410 essential component of some other security mechanisms, notably IPsec. 412 Although not widely deployed on the Internet at the time of the 413 writing of this document, it offers the potential to provide a secure 414 mechanism for mapping domain names to IP protocol addresses. It may 415 also be used to securely associate other information with a DNS name. 416 This information may be as simple as a service that is supported on a 417 given node, or a key to be used with IPsec for negotiating a secure 418 session. (Note that the concept of storing application keys in the 419 DNS is still controversial.) 421 5.8. Security/Multipart 423 Security/Multiparts [RFC1847] are the preferred mechanism for 424 protecting email. More precisely, it is the MIME framework within 425 which encryption and/or digital signatures are embedded. Both S/MIME 426 and OpenPGP (see below) use Security/Multipart for their encoding. 427 Conforming mail readers can easily recognize and process the 428 cryptographic portions of the mail. 430 Security/Multiparts represents one form of "object security", where 431 the object of interest to the end user is protected, independent of 432 transport mechanism, intermediate storage, etc. Currently, there is 433 no general form of object protection available in the Internet. 435 5.9. Digital Signatures 437 One of the strongest forms of challenge/response authentication is 438 based on digital signatures. Using public key cryptography is 439 preferable to schemes based on secret key ciphers because no server 440 needs a copy of the client's secret. Rather, the client has a 441 private key; servers have the corresponding public key. 443 Using digital signatures properly is tricky. A client should never 444 sign the exact challenge sent to it, since there are several subtle 445 number-theoretic attacks that can be launched in such situations. 447 The Digital Signature Standard [DSS] and RSA [RSA] are both good 448 choices; each has its advantages. Signing with DSA requires the use 449 of good random numbers [RFC1750]. If the enemy can recover the 450 random number used for any given signature, or if you use the same 451 random number for two different documents, your private key can be 452 recovered. DSS has much better performance than RSA for generating 453 new private keys, and somewhat better performance generating 454 signatures, while RSA has much better performance for verifying 455 signatures. 457 5.10. OpenPGP and S/MIME 459 Digital signatures can be used to build "object security" 460 applications which can be used to protect data in store and forward 461 protocols such as electronic mail. 463 At this writing, two different secure mail protocols, OpenPGP 464 [OpenPGP] and S/MIME [S/MIME], have been proposed to replace PEM 465 [PEM]. It is not clear which, if either, will succeed. While 466 specified for use with secure mail, both can be adapted to protect 467 data carried by other protocols. Both use certificates to identify 468 users; both can provide secrecy and authentication of mail messages; 469 however, the certificate formats are very different. Historically, 470 the difference between PGP-based mail and S/MIME-based mail has been 471 the style of certificate chaining. In S/MIME, users possess X.509 472 certificates; the certification graph is a tree with a very small 473 number of roots. By contrast, PGP uses the so-called "web of trust", 474 where any user can sign anyone else's certificate. This 475 certification graph is really an arbitrary graph or set of graphs. 477 With any certificate scheme, trust depends on two primary 478 characteristics. First, it must start from a known-reliable source- 479 -either an X.509 root, or someone highly trusted by the verifier, 480 often him or herself. Second, the chain of signatures must be 481 reliable. That is, each node in the certification graph is crucial; 482 if it is dishonest or has been compromised, any certificates it has 483 vouched for cannot be trusted. All other factors being equal (and 484 they rarely are), shorter chains are preferable. 486 Some of the differences reflect a tension between two philosophical 487 positions represented by these technologies. Others resulted from 488 having separate design teams. 490 S/MIME is designed to be "fool proof." That is, very little end-user 491 configuration is required. Specifically, end-users do not need to be 492 aware of trust relationships, etc. The idea is that if an S/MIME 493 client says, "This signature is valid", the user should be able to 494 "trust" that statement at face value without needing to understand 495 the underlying implications. 497 To achieve this, S/MIME is typically based on a limited number of 498 "root" Certifying Authorities (CAs). The goal is to build a global 499 trusted certificate infrastructure. 501 The down side to this approach is that it requires a deployed public 502 key infrastructure before it will work. Two end-users may not be able 503 to simply obtain S/MIME-capable software and begin communicating 504 securely. This is not a limitation of the protocol, but a typical 505 configuration restriction for commonly available software. One or 506 both of them may need to obtain a certificate from a mutually trusted 507 CA; furthermore, that CA must already be trusted by their mail 508 handling software. This process may involve cost and legal 509 obligations. This ultimately results in the technology being harder 510 to deploy, particularly in an environment where end-users do not 511 necessarily appreciate the value received for the hassle incurred. 513 The PGP "web of trust" approach has the advantage that two end-users 514 can just obtain PGP software and immediately begin to communicate 515 securely. No infrastructure is required and no fees and legal 516 agreements need to be signed to proceed. As such PGP appeals to 517 people who need to establish ad-hoc security associations. 519 The down side to PGP is that it requires end-users to have an 520 understanding of the underlying security technology in order to make 521 effective use of it. Specifically it is fairly easy to fool a naive 522 users to accept a "signed" message that is in fact a forgery. 524 To date PGP has found great acceptance between security-aware 525 individuals who have a need for secure e-mail in an environment 526 devoid of the necessary global infrastructure. 528 By contrast, S/MIME works well in a corporate setting where a secure 529 internal CA system can be deployed. It does not require a lot of 530 end-user security knowledge. S/MIME can be used between institutions 531 by carefully setting up cross certification, but this is harder to do 532 than it seems. 534 As of this writing a global certificate infrastructure continues to 535 elude us. Questions about a suitable business model, as well as 536 privacy considerations, may prevent one from ever emerging. 538 5.11. Firewalls and Topology 540 Firewalls are a topological defense mechanism. That is, they rely on 541 a well-defined boundary between the good "inside" and the bad 542 "outside" of some domain, with the firewall mediating the passage of 543 information. While firewalls can be very valuable if employed 544 properly, there are limits to their ability to protect a network. 546 The first limitation, of course, is that firewalls cannot protect 547 against inside attacks. While the actual incidence rate of such 548 attacks is not known (and is probably unknowable), there is no doubt 549 that it is substantial, and arguably constitutes a majority of 550 security problems. More generally, given that firewalls require a 551 well-delimited boundary, to the extent that such a boundary does not 552 exist, firewalls do not help. Any external connections, whether they 553 are protocols that are deliberately passed through the firewall, 554 links that are tunneled through, unprotected wireless LANs, or direct 555 external connections from nominally-inside hosts, weaken the 556 protection. Firewalls tend to become less effective over time as 557 users tunnel protocols through them and may have inadequate security 558 on the tunnel endpoints. If the tunnels are encrypted, there is no 559 way for the firewall to censor them. An oft-cited advantage of 560 firewalls is that they hide the existence of internal hosts from 561 outside eyes. Given the amount of leakage, however, the likelihood 562 of successfully hiding machines is rather low. 564 In a more subtle vein, firewalls hurt the end-to-end model of the 565 Internet and its protocols. Indeed, not all protocols can be passed 566 safely or easily through firewalls. Sites that rely on firewalls for 567 security may find themselves cut off from new and useful aspects of 568 the Internet. 570 Firewalls work best when they are used as one element of a total 571 security structure. For example, a strict firewall may be used to 572 separate an exposed Web server from a back-end database, with the 573 only opening the communication channel between the two. Similarly, a 574 firewall that permitted only encrypted tunnel traffic could be used 575 to secure a piece of a VPN. On the other hand, in that case the 576 other end of the VPN would need to be equally secured. 578 5.12. Kerberos 580 Kerberos [RFC1510] provides a mechanism for two entities to 581 authenticate each other and exchange keying material. On the client 582 side, an application obtains a Kerberos "ticket" and "authenticator." 583 These items, which should be considered opaque data, are then 584 communicated from client to server. The server can then verify their 585 authenticity. Both sides may then ask the Kerberos software to 586 provide them with a session key which can be used to protect or 587 encrypt data. 589 Kerberos may be used by itself in a protocol. However, it is also 590 available as a mechanism under SASL and GSSAPI. 592 5.13. SSH 594 SSH provides a secure connection between client and server. It 595 operates very much like TLS; however, it is optimized as a protocol 596 for remote connections on terminal-like devices. One of its more 597 innovative features is its support for "tunneling" other protocols 598 over the SSH-protected TCP connection. This feature has permitted 599 knowledgeable security people to perform such actions as reading and 600 sending e-mail or news via insecure servers over an insecure network. 601 It is not a substitute for a true VPN, but it can often be used in 602 place of one. 604 6. Insecurity Mechanisms 606 Some common security mechanisms are part of the problem rather than 607 part of the solution. 609 6.1. Plaintext Passwords 611 Plaintext passwords are the most common security mechanism in use 612 today. Unfortunately, they are also the weakest. When not protected 613 by an encryption layer, they are completely unacceptable. Even when 614 used with encryption, plaintext passwords are quite weak, since they 615 must be transmitted to the remote system. If that system has been 616 compromised or if the encryption layer does not include effective 617 authentication of the server to the client, an enemy can collect the 618 passwords and possibly use them against other targets. 620 Another weakness arises because of common implementation techniques. 621 It is considered good form [MT79] for the host to store a one-way 622 hash of the users' passwords, rather than their plaintext form. 623 However, that may preclude migrating to stronger authentication 624 mechanisms, such as HMAC-based challenge/response. 626 The strongest attack against passwords, other than eavesdropping, is 627 password-guessing. With a suitable program and dictionary (and these 628 are widely available), 20-30% of passwords can be guessed in most 629 environments [Klein90]. 631 6.2. Address-Based Authentication 633 Another common security mechanism is address-based authentication. 634 At best, it can work in highly constrained environments. If your 635 environment consists of a small number of machines, all tightly 636 administered, secure systems run by trusted users, and if the network 637 is guarded by a router that blocks source-routing and prevents 638 spoofing of your source addresses, and you know there are no wireless 639 bridges, and if you restrict address-based authentication to machines 640 on that network, you are probably safe. But these conditions are 641 rarely met. 643 Among the threats are ARP-spoofing, abuse of local proxies, 644 renumbering, routing table corruption or attacks, DHCP, IP address 645 spoofing (a particular risk for UDP-based protocols), sequence number 646 guessing, and source-routed packets. All of these can be quite 647 potent. 649 6.3. Name-Based Authentication 651 Name-based authentication has all of the problems of address-based 652 authentication and adds new ones: attacks on the DNS [Bell95] and 653 lack of a one to one mapping between addresses and names. At a 654 minimum, a process that retrieves a host name from the DNS should 655 retrieve the corresponding address records and cross-check. 656 Techniques such as DNS cache contamination can often negate such 657 checks. 659 DNSSEC provides protection against this sort of attack. However, it 660 does nothing to enhance the reliability of the underlying address. 661 Further, the technique generates a lot of false alarms. These lookups 662 do not provide reliable information to a machine, though they might 663 be a useful debugging tool for humans and could be useful in logs 664 when trying to reconstruct how and attack took place. 666 7. Security Considerations 668 No security mechanisms are perfect. If nothing else, any network- 669 based security mechanism can be thwarted by compromise of the 670 endpoints. That said, each of the mechanisms described here has its 671 own limitations. Any decision to adopt a given mechanism should 672 weigh all of the possible failure modes. These in turn should be 673 weighed against the risks to the endpoint of a security failure. 675 8. Acknowledgements 677 Brian Carpenter, Tony Hain, and Marcus Leech made a number of useful 678 suggestions. Much of the substance comes from the participants in 679 the IAB Security Architecture Workshop. 681 9. References 683 [RFC2316] "Report of the IAB Security Architecture Workshop". S. 684 Bellovin. April 1998. 686 [RFC2289] "A One-Time Password System". N. Haller, C. Metz, P. 687 Nesser, M. Straw. February 1998. 689 [RFC2104] "HMAC: Keyed-Hashing for Message Authentication". H. 690 Krawczyk, M. Bellare, R. Canetti. February 1997. 692 [RFC1321] "The MD5 Message-Digest Algorithm". R. Rivest. April 693 1992. 695 [RFC2246] "The TLS Protocol Version 1.0. T. Dierks, C. Allen. 696 January 1999." 698 [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature 699 Option". A. Hefferman. August 1998. 701 [RFC2401] "Security Architecture for the Internet Protocol". S. 702 Kent, R. Atkinson. November 1998. 704 [RFC2402] "IP Authentication Header. S. Kent, R. Atkinson. November 705 1998." 707 [RFC2406] "IP Encapsulating Security Payload (ESP). S. Kent, R. 708 Atkinson. November 1998." 710 [RFC2407] "The Internet IP Security Domain of Interpretation for 711 ISAKMP. D. Piper. November 1998." 713 [RFC2411] "IP Security Document Roadmap". R. Thayer, N. Doraswamy, 714 R. Glenn. November 1998. 716 [RFC2744] "Generic Security Service API Version 2 : C-bindings. J. 717 Wray. January 2000." 719 [RFC3174] "US Secure Hash Algorithm 1 (SHA1)". D. Eastlake, 3rd, 720 and P. Jones. September 2001. 722 [Hain99] "Architectural Implications of NAT". T. Hain. April 723 1999. Work in progress. 725 [Bell95] "Using the Domain Name System for System Break-Ins". 726 Proc. Fifth Usenix Security Conference, 1995. 728 [Bell98] "Cryptography and the Internet", S.M. Bellovin, in 729 Proceedings of CRYPTO '98, August 1998. 731 [RFC2222] "Simple Authentication and Security Layer (SASL)". J. 732 Myers. October 1997. 734 [RFC2535] "Domain Name System Security Extensions". D. Eastlake. 735 March 1999. 737 [RFC1847] "Security Multiparts for MIME: Multipart/Signed and 738 Multipart/Encrypted". J. Galvin, S. Murphy, S. Crocker & N. Freed. 739 October 1995. 741 [DSS] "Digital Signature Standard". NIST. May 1994. FIPS 742 186. 744 [RSA] "A Method for Obtaining Digital Signatures and 745 Public-Key Cryptosystems". R. Rivest, A. Shamir, L.M. Adleman, 746 Communications of the ACM, February 1978. 748 [RFC1750] "Randomness Recommendations for Security". D. Eastlake, 749 3rd, S. Crocker & J. Schiller. December 1994. 751 [MT79] "UNIX Password Security", R.H. Morris and K. 752 Thompson, Communications of the ACM. November 1979. 754 [Klein90] "'Foiling the Cracker': A Survey of, and Implications 755 to, Password Security". D. Klein. Usenix UNIX Security Workshop, 756 August 1990. 758 10. Author Information 760 Steven M. Bellovin 761 AT&T Labs Research 762 Shannon Laboratory 763 180 Park Avenue 764 Florham Park, NJ 07974 765 USA 766 Phone: +1 973-360-8656 767 email: smb@research.att.com 769 Charlie Kaufman 770 IBM - WTF5 771 4 Technology Park Drive 772 Westford, MA 01886 773 USA 774 Phone: +1 978-399-6383 775 email: ckaufman@us.ibm.com 777 Jeffrey I. Schiller 778 Massachusetts Institute of Technology 779 Room W92-190 780 77 Massachusetts Avenue 781 Cambridge, MA 02139-4307 782 USA 783 Phone: +1 617-253-8400 784 email: jis@mit.edu