idnits 2.17.1 draft-iab-secmech-03.txt: 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 19 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 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 2003) is 7584 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: 'RFC 3515' is mentioned on line 459, but not defined == Missing Reference: 'OpenPGP' is mentioned on line 490, but not defined == Missing Reference: 'PEM' is mentioned on line 491, but not defined == Missing Reference: 'RFC1510' is mentioned on line 606, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Unused Reference: 'RFC3261' is defined on line 800, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-03 -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Internet Architecture Board 3 Internet Draft S. Bellovin, Ed. 4 Expires: January 2004 J. Schiller, Ed. 5 C. Kaufman, Ed. 6 July 2003 8 Security Mechanisms for the Internet 10 draft-iab-secmech-03.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 29, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 Security must be built into Internet Protocols for those protocols to 42 offer their services securely. Many security problems can be traced 43 to improper implementations. However, even a proper implementation 44 will have security problems if the fundamental protocol is itself 45 exploitable. Exactly how security should be implemented in a 46 protocol will vary, because of the structure of the protocol itself. 47 However, there are many protocols for which standard Internet 48 security mechanisms, already developed, may be applicable. The 49 precise one that is appropriate in any given situation can vary. We 50 review a number of different choices, explaining the properties of 51 each. 53 1. Introduction 55 Internet Security compromises can be divided into several classes, 56 ranging from Denial of Service to Host Compromise. Denial of Service 57 attacks based on sheer volume of traffic are beyond the scope of this 58 document, though they are the subject of much ongoing discussion and 59 research. It is important to note that many such attacks are made 60 more difficult by good security practices. Host Compromise (most 61 commonly caused by undetected Buffer Overflows) represent flaws in 62 individual implementations rather than flaws in protocols. 63 Nevertheless, carefully designed protocols can make such flaws less 64 likely to occur and harder to exploit. 66 However there are security compromises that are facilitated by the 67 very protocols that are in use on the Internet. If a security problem 68 is inherent in a protocol, no manner of implementation will be able 69 to prevent the problem. 71 It is therefore vitally important that protocols developed for the 72 Internet provide this fundamental security. 74 Exactly how a protocol should be secured depends on the protocol 75 itself as well as the security needs of the protocol. However we have 76 developed a number of standard security mechanisms in the IETF. In 77 many cases appropriate application of these mechanisms can provide 78 the necessary security for a protocol. 80 A number of possible mechanisms can be used to provide security on 81 the Internet. Which one should be selected depends on many different 82 factors. We attempt here to provide guidance, spelling out the 83 factors and the currently-standardized (or about-to-be-standardized) 84 solutions, as discussed at the IAB Security Architecture Workshop 85 [RFC2316]. 87 Security, however, is an art, not a science. Attempting to follow a 88 recipe blindly can lead to disaster. As always, good taste in 89 protocol design should be exercised. 91 Finally, security mechanisms are not magic pixie dust that can be 92 sprinkled over completed protocols. It is rare that security can be 93 bolted on later. Good designs--that is, secure, clean, and efficient 94 designs--occur when the security mechanisms are crafted along with 95 the protocol. No conceivable exercise in cryptography can secure a 96 protocol with flawed semantic assumptions. 98 2. Decision Factors 100 2.1. Threat Model 102 The most important factor in choosing a security mechanism is the 103 threat model. That is, who may be expected to attack what resource, 104 using what sorts of mechanisms? A low-value target, such as a Web 105 site that offers public information only, may not merit much 106 protection. Conversely, a resource that if compromised could expose 107 significant parts of the Internet infrastructure--say, a major 108 backbone router or high-level Domain Name Server--should be protected 109 by very strong mechanisms. The value of a target to an attacker 110 depends on the purpose of the attack. If the purpose is to access 111 sensitive information, all systems that handle this information or 112 mediate access to it are valuable. If the purpose is to wreak havoc, 113 systems on which large parts of the Internet depend are exceedingly 114 valuable. Even if only public information is posted on a web site, 115 changing its contents can cause embarrassment to its owner and could 116 result in substantial damage. It is difficult when designing a 117 protocol to predict what uses that protocol will someday have. 119 All Internet connected systems require a minimum amount of 120 protection. Starting in 2000 and continuing to the present, we have 121 witnessed the advent of a new type of Internet security attack: an 122 Internet "worm" program that seeks out and automatically attacks 123 systems that are vulnerable to compromise via a number of attacks 124 built into the worm program itself. These worm programs can 125 compromise literally thousands of systems within a very short period 126 of time. Note that the first Internet Worm was the "Morris" worm of 127 1988. However it was not followed up with similar programs for over 128 12 years! 130 As of the writing of this document, all of these worms have taken 131 advantage of programming errors in the implementation of otherwise 132 reasonably secure protocols. However, it is not hard to envision an 133 attack that targets a fundamental security flaw in a widely deployed 134 protocol. It is therefore imperative that we strive to minimize such 135 flaws in the protocols we design. 137 The value of a target to an attacker may depend on where it is 138 located. A network monitoring station that is physically on a 139 backbone cable is a major target, since it could easily be turned 140 into an eavesdropping station. The same machine, if located on a 141 stub net and used for word processing, would be of much less use to a 142 sophisticated attacker, and hence would be at significantly less 143 risk. 145 One must also consider what sorts of attacks may be expected. At a 146 minimum, eavesdropping must be seen as a serious threat; there have 147 been very many such incidents since at least 1993. Often, active 148 attacks--that is, attacks that involve insertion or deletion of 149 packets by the attacker--are a risk as well. It is worth noting that 150 such attacks can be launched with off-the-shelf tools, and have in 151 fact been observed "in the wild". Of particular interest is a form of 152 attack called "session hijacking", where someone on a link between 153 the two communicating parties wait for authentication to complete and 154 then impersonate one of the parties and continue the connection with 155 the other. 157 One of the most important tools available to us for securing 158 protocols is cryptography. Cryptography permits us to apply various 159 kinds of protection to data as it traverses the network, without 160 having to depend on any particular security properties of the network 161 itself. This is important because the Internet, by its distributed 162 management and control, cannot be considered a trustworthy media in 163 and of itself. Its security derives from the mechanisms that we build 164 into the protocols themselves, independent of the underlying media or 165 network operators. 167 Finally, of course, there is the cost to the defender of using 168 cryptography. This cost is dropping rapidly; Moore's Law, plus the 169 easy availability of cryptographic components and toolkits, makes it 170 relatively easy to use strong protective techniques. Although there 171 are exceptions--public key operations are still expensive, perhaps 172 prohibitively so if the cost of each public-key operation is spread 173 over too few transactions--careful engineering design can generally 174 let us spread this cost over many transactions. 176 In general, the default today should be to use the strongest 177 cryptography available in any protocol. Strong cryptography often 178 costs no more, and sometimes less, then weaker cryptography. The 179 actual performance cost of an algorithm is often unrelated to the 180 security it provides. Depending on the hardware available, 181 cryptography can be performed at very high rates (1+Gbps), and even 182 in software its performance impact is shrinking over time. 184 2.2. A Word about Mandatory Mechanisms 186 We have evolved in the IETF the notion of "mandatory to implement" 187 mechanisms. This philosophy evolves from our primary desire to ensure 188 interoperability between different implementations of a protocol. If 189 a protocol offers many options for how to perform a particular task, 190 but fails to provide for at least one that all must implement, it may 191 be possible that multiple, non-interoperable implementations may 192 result. This is the consequence of the selection of non-overlapping 193 mechanisms being deployed in the different implementations. 195 Although a given protocol may make use of only one or a few security 196 mechanisms, these mechanisms themselves often can make use of several 197 cryptographic systems. The various cryptographic systems vary in 198 strength and performance. However, in many protocols we need to 199 specify a "mandatory to implement" to ensure that any two 200 implementations will eventually be able to negotiate a common 201 cryptographic system between them. 203 There are some protocols that were originally designed to be run in a 204 very limited domain. It is often argued that the domain of 205 implementation for a particular protocol is sufficiently well defined 206 and secure that the protocol itself need not provide any security 207 mechanisms. 209 History has shown this argument to be wrong. Inevitably, successful 210 protocols - even if developed for limited use - wind up used in a 211 broader environment, where the initial security assumptions do not 212 hold. 214 To solve this problem, the IETF requires that *ALL* protocols provide 215 appropriate security mechanisms, even when their domain of 216 application is at first believed to be very limited. 218 It is important to understand that mandatory mechanisms are mandatory 219 to *implement*. It is not necessarily mandatory that end-users 220 actually use these mechanisms. If an end-user knows that they are 221 deploying a protocol over a "secure" network, then they may choose to 222 disable security mechanisms that they believe are adding insufficient 223 value as compared to their performance cost. (We are generally 224 skeptical of the wisdom of disabling strong security even then, but 225 that is beyond the scope of this document.) 227 Insisting that certain mechanisms are mandatory to implement means 228 that those end-users who need the protocol provided by the security 229 mechanism have it available when needed. Particularly with security 230 mechanisms, mandatory to implement does not imply good default. If a 231 mandatory to implement algorithm is old and weak, it is better to 232 disable it when a stronger algorithm is available. 234 2.3. Granularity of Protection 236 Some security mechanisms can protect an entire network. While this 237 economizes on hardware, it can leave the interior of such networks 238 open to attacks from the inside. Other mechanisms can provide 239 protection down to the individual user of a timeshared machine, 240 though perhaps at risk of user impersonation if the machine has been 241 compromised. 243 When assessing the desired granularity of protection, protocol 244 designers should take into account likely usage patterns, 245 implementation layers (see below), and deployability. If a protocol 246 is likely to be used only from within a secure cluster of machines 247 (say, a Network Operations Center), subnet granularity may be 248 appropriate. By contrast, a security mechanism peculiar to a single 249 application is best embedded in that application, rather than inside 250 TCP; otherwise, deployment will be very difficult. 252 2.4. Implementation Layer 254 Security mechanisms can be located at any layer. In general, putting 255 a mechanism at a lower layer protects a wider variety of higher-layer 256 protocols, but may not be able to protect them as well. A link-layer 257 encryptor can protect not just IP, but even ARP packets. However, 258 its reach is just that one link. Conversely, a signed email message 259 is protected even if sent through many store-and-forward mail 260 gateways, can identify the actual sender, and the signature can be 261 verified long after the message is delivered. However, only that one 262 type of message is protected. Messages of similar formats, such as 263 some Netnews postings, are not protected unless the mechanism is 264 specifically adapted and then implemented in the news-handling 265 programs. 267 3. Standard Security Mechanisms 269 3.1. One-Time Passwords 271 One-time password schemes, such as that described in [RFC2289], are 272 very much stronger than conventional passwords. The host need not 273 store a copy of the user's password, nor is it ever transmitted over 274 the network. However, there are some risks. Since the transmitted 275 string is derived from a user-typed password, guessing attacks may 276 still be feasible. (Indeed, a program to launch just this attack is 277 readily available.) Furthermore, the user's ability to login 278 necessarily expires after a predetermined number of uses. While in 279 many cases this is a feature, an implementation most likely needs to 280 provide a way to reinitialize the authentication database, without 281 requiring that the new password be sent in the clear across the 282 network. 284 There are commercial hardware authentication tokens. Apart from the 285 session hijacking issue, support for such tokens (especially 286 challenge/response tokens, where the server sends a different random 287 number for each authentication attempt) may require extra protocol 288 messages. 290 3.2. HMAC 292 HMAC [RFC2104] is the preferred shared-secret authentication 293 technique. If both sides know the same secret key, HMAC can be used 294 to authenticate any arbitrary message. This includes random 295 challenges, which means that HMAC can be adapted to prevent replays 296 of old sessions. 298 An unfortunate disadvantage of using HMAC for connection 299 authentication is that the secret must be known in the clear by both 300 parties, making this undesirable when keys are long-lived. 302 When suitable, HMAC should be used in preference to older techniques, 303 notably keyed hash functions. Simple keyed hashes based on MD5 304 [RFC1321], such as that used in the BGP session security mechanism 305 [RFC2385], are especially to be avoided in new protocols, given the 306 hints of weakness in MD5. 308 HMAC can be implemented using any secure hash function, including MD5 309 and SHA-1 [RFC3174]. SHA-1 is preferable for new protocols because 310 it is more frequently used for this purpose and may be more secure. 312 It is important to understand that an HMAC-based mechanism needs to 313 be employed on every protocol data unit (aka packet). It is a mistake 314 to use an HMAC-based system to authenticate the beginning of a TCP 315 session and then send all remaining data without any protection. 317 Attack programs exist that permit a TCP session to be stolen. An 318 attacker merely needs to use such a tool to steal a session after the 319 HMAC step is performed. 321 3.3. IPsec 323 IPsec [RFC2401],[RFC2402],[RFC2406],[RFC2407],[RFC2411] is the 324 generic IP-layer encryption and authentication protocol. As such, it 325 protects all upper layers, including both TCP and UDP. Its normal 326 granularity of protection is host-to-host, host-to-gateway, and 327 gateway-to-gateway. The specification does permit user-granularity 328 protection, but this is comparatively rare. As such, IPsec is 329 currently inappropriate when host-granularity is too coarse. 331 Because IPsec is installed at the IP layer, it is rather intrusive to 332 the networking code. Implementing it generally requires either new 333 hardware or a new protocol stack. On the other hand, it is fairly 334 transparent to applications. Applications running over IPsec can have 335 improved security without changing their protocols at all. But at 336 least until IPsec is more widely deployed, most applications should 337 not assume they are running atop IPsec as an alternative to 338 specifying their own security mechanisms. Most modern operating 339 systems have IPsec available; most routers do not, at least for the 340 control path. Even systems implementing IPsec are likely today to not 341 expose APIs necessary for applications to take advantage of its 342 authentication. 344 The key management for IPsec can use either certificates or shared 345 secrets. For all the obvious reasons, certificates are preferred; 346 however, they may present more of a headache for the system manager. 348 There is strong potential for conflict between IPsec and NAT 349 [RFC2993]. NAT does not easily coexist with any protocol containing 350 embedded IP address; with IPsec, every packet, for every protocol, 351 contains such addresses, if only in the headers. The conflict can 352 sometimes be avoided by using tunnel mode, but that is not always an 353 appropriate choice for other reasons. There is ongoing work to make 354 IPsec pass through NAT more easily [NATIKE]. 356 Most current IPsec usage is for virtual private networks. Assuming 357 that the other constraints are met, IPsec is the security protocol of 358 choice for VPN-like situations, including the remote access scenario 359 where a single machine tunnels back into its home network over the 360 internet using IPsec. 362 3.4. TLS 364 TLS [RFC2246] provides an encrypted, authenticated channel that runs 365 on top of TCP. While TLS was originally designed for use by Web 366 browsers, it is by no means restricted to such. In general, though, 367 each application that wishes to use TLS will need to be converted 368 individually. 370 Generally, the server side is always authenticated by a certificate. 371 Clients may possess certificates, too, providing mutual 372 authentication, though this is rarely deployed. It's an unfortunate 373 reality that even server side authentication it not as secure in 374 practice as the cryptography would imply because most implementations 375 allow users to ignore authentication failures (by clicking OK to a 376 warning) and most users routinely do so [Bell98]. Designers should 377 thus be wary of demanding plaintext passwords, even over TLS- 378 protected connections. (This requirement can be relaxed if it is 379 likely that implementations will be able to verify the authenticity 380 and authorization of the server's certificate.) 382 Although application modification is generally required to make use 383 of TLS, there exist toolkits, both free and commercial, that provide 384 implementations. These are designed to be incorporated into the 385 application's code. An application using TLS is more likely to be 386 able to assert application specific certificate policies than one 387 using IPsec. 389 3.5. SASL 391 SASL [RFC2222] is a framework for negotiating an authentication and 392 encryption mechanism to be used over a TCP stream. As such, its 393 security properties are those of the negotiated mechanism. 394 Specifically, unless the negotiated mechanism authenticates all of 395 the subsequent messages or underlying protection protocol such as TLS 396 is used, TCP connections are vulnerable to session stealing. 398 If you need to use TLS (or IPSec) under SASL, why bother with SASL in 399 the first place? Why not simply use the authentication facilities of 400 TLS and be done with it? 402 The answer here is subtle. TLS makes extensive use of certificates 403 for authentication. As commonly deployed, only servers have 404 certificates, whereas clients go unauthenticated (at least by the TLS 405 processing itself). 407 SASL permits the use of more traditional client authentication 408 technologies, such as passwords (one-time or otherwise). A powerful 409 combination is TLS for underlying protection and authentication of 410 the server, and a SASL-based system for authenticating clients. Care 411 must be taken to avoid man-in-the-middle vulnerabilities when 412 different authentication techniques are used in different directions. 414 3.6. GSS-API 416 GSS-API [RFC2744] provides a framework for applications to use when 417 they require authentication, integrity, and/or confidentiality. 418 Unlike SASL, GSS-API can be used easily with UDP-based applications. 419 It provides for the creation of opaque authentication tokens (aka 420 chunks of memory) which may be embedded in a protocol's data units. 421 Note that the security of GSS-API-protected protocols depends on the 422 underlying security mechanism; this must be evaluated independently. 423 Similar considerations apply to interoperability, of course. 425 3.7. DNSSEC 427 DNSSEC [RFC2535] digitally signs DNS records. It is an essential 428 tool for protecting against DNS cache contamination attacks [Bell95]; 429 these in turn can be used to defeat name-based authentication and to 430 redirect traffic to or past an attacker. The latter makes DNSSEC an 431 essential component of some other security mechanisms, notably IPsec. 433 Although not widely deployed on the Internet at the time of the 434 writing of this document, it offers the potential to provide a secure 435 mechanism for mapping domain names to IP protocol addresses. It may 436 also be used to securely associate other information with a DNS name. 437 This information may be as simple as a service that is supported on a 438 given node, or a key to be used with IPsec for negotiating a secure 439 session. Note that the concept of storing general purpose 440 application keys in the DNS has been deprecated, but standardization 441 of storing keys for particular applications - in particular IPsec - 442 is proceeding. 444 3.8. Security/Multipart 446 Security/Multiparts [RFC1847] are the preferred mechanism for 447 protecting email. More precisely, it is the MIME framework within 448 which encryption and/or digital signatures are embedded. Both S/MIME 449 and OpenPGP (see below) use Security/Multipart for their encoding. 450 Conforming mail readers can easily recognize and process the 451 cryptographic portions of the mail. 453 Security/Multiparts represents one form of "object security", where 454 the object of interest to the end user is protected, independent of 455 transport mechanism, intermediate storage, etc. Currently, there is 456 no general form of object protection available in the Internet. 458 For a good example of using S/MIME outside the context of email, see 459 Session Initiation Protocol [RFC 3515]. 461 3.9. Digital Signatures 463 One of the strongest forms of challenge/response authentication is 464 based on digital signatures. Using public key cryptography is 465 preferable to schemes based on secret key ciphers because no server 466 needs a copy of the client's secret. Rather, the client has a 467 private key; servers have the corresponding public key. 469 Using digital signatures properly is tricky. A client should never 470 sign the exact challenge sent to it, since there are several subtle 471 number-theoretic attacks that can be launched in such situations. 473 The Digital Signature Standard [DSS] and RSA [RSA] are both good 474 choices; each has its advantages. Signing with DSA requires the use 475 of good random numbers [RFC1750]. If the enemy can recover the 476 random number used for any given signature, or if you use the same 477 random number for two different documents, your private key can be 478 recovered. DSS has much better performance than RSA for generating 479 new private keys, and somewhat better performance generating 480 signatures, while RSA has much better performance for verifying 481 signatures. 483 3.10. OpenPGP and S/MIME 485 Digital signatures can be used to build "object security" 486 applications which can be used to protect data in store and forward 487 protocols such as electronic mail. 489 At this writing, two different secure mail protocols, OpenPGP 490 [OpenPGP] and S/MIME [S/MIME], have been proposed to replace PEM 491 [PEM]. It is not clear which, if either, will succeed. While 492 specified for use with secure mail, both can be adapted to protect 493 data carried by other protocols. Both use certificates to identify 494 users; both can provide secrecy and authentication of mail messages; 495 however, the certificate formats are very different. Historically, 496 the difference between PGP-based mail and S/MIME-based mail has been 497 the style of certificate chaining. In S/MIME, users possess X.509 498 certificates; the certification graph is a tree with a very small 499 number of roots. By contrast, PGP uses the so-called "web of trust", 500 where any user can sign anyone else's certificate. This 501 certification graph is really an arbitrary graph or set of graphs. 503 With any certificate scheme, trust depends on two primary 504 characteristics. First, it must start from a known-reliable 505 source--either an X.509 root, or someone highly trusted by the 506 verifier, often him or herself. Second, the chain of signatures must 507 be reliable. That is, each node in the certification graph is 508 crucial; if it is dishonest or has been compromised, any certificates 509 it has vouched for cannot be trusted. All other factors being equal 510 (and they rarely are), shorter chains are preferable. 512 Some of the differences reflect a tension between two philosophical 513 positions represented by these technologies. Others resulted from 514 having separate design teams. 516 S/MIME is designed to be "fool proof". That is, very little end-user 517 configuration is required. Specifically, end-users do not need to be 518 aware of trust relationships, etc. The idea is that if an S/MIME 519 client says, "This signature is valid", the user should be able to 520 "trust" that statement at face value without needing to understand 521 the underlying implications. 523 To achieve this, S/MIME is typically based on a limited number of 524 "root" Certifying Authorities (CAs). The goal is to build a global 525 trusted certificate infrastructure. 527 The down side to this approach is that it requires a deployed public 528 key infrastructure before it will work. Two end-users may not be able 529 to simply obtain S/MIME-capable software and begin communicating 530 securely. This is not a limitation of the protocol, but a typical 531 configuration restriction for commonly available software. One or 532 both of them may need to obtain a certificate from a mutually trusted 533 CA; furthermore, that CA must already be trusted by their mail 534 handling software. This process may involve cost and legal 535 obligations. This ultimately results in the technology being harder 536 to deploy, particularly in an environment where end-users do not 537 necessarily appreciate the value received for the hassle incurred. 539 The PGP "web of trust" approach has the advantage that two end-users 540 can just obtain PGP software and immediately begin to communicate 541 securely. No infrastructure is required and no fees and legal 542 agreements need to be signed to proceed. As such PGP appeals to 543 people who need to establish ad-hoc security associations. 545 The down side to PGP is that it requires end-users to have an 546 understanding of the underlying security technology in order to make 547 effective use of it. Specifically it is fairly easy to fool a naive 548 users to accept a "signed" message that is in fact a forgery. 550 To date PGP has found great acceptance between security-aware 551 individuals who have a need for secure e-mail in an environment 552 devoid of the necessary global infrastructure. 554 By contrast, S/MIME works well in a corporate setting where a secure 555 internal CA system can be deployed. It does not require a lot of 556 end-user security knowledge. S/MIME can be used between institutions 557 by carefully setting up cross certification, but this is harder to do 558 than it seems. 560 As of this writing a global certificate infrastructure continues to 561 elude us. Questions about a suitable business model, as well as 562 privacy considerations, may prevent one from ever emerging. 564 3.11. Firewalls and Topology 566 Firewalls are a topological defense mechanism. That is, they rely on 567 a well-defined boundary between the good "inside" and the bad 568 "outside" of some domain, with the firewall mediating the passage of 569 information. While firewalls can be very valuable if employed 570 properly, there are limits to their ability to protect a network. 572 The first limitation, of course, is that firewalls cannot protect 573 against inside attacks. While the actual incidence rate of such 574 attacks is not known (and is probably unknowable), there is no doubt 575 that it is substantial, and arguably constitutes a majority of 576 security problems. More generally, given that firewalls require a 577 well-delimited boundary, to the extent that such a boundary does not 578 exist, firewalls do not help. Any external connections, whether they 579 are protocols that are deliberately passed through the firewall, 580 links that are tunneled through, unprotected wireless LANs, or direct 581 external connections from nominally-inside hosts, weaken the 582 protection. Firewalls tend to become less effective over time as 583 users tunnel protocols through them and may have inadequate security 584 on the tunnel endpoints. If the tunnels are encrypted, there is no 585 way for the firewall to censor them. An oft-cited advantage of 586 firewalls is that they hide the existence of internal hosts from 587 outside eyes. Given the amount of leakage, however, the likelihood 588 of successfully hiding machines is rather low. 590 In a more subtle vein, firewalls hurt the end-to-end model of the 591 Internet and its protocols. Indeed, not all protocols can be passed 592 safely or easily through firewalls. Sites that rely on firewalls for 593 security may find themselves cut off from new and useful aspects of 594 the Internet. 596 Firewalls work best when they are used as one element of a total 597 security structure. For example, a strict firewall may be used to 598 separate an exposed Web server from a back-end database, with the 599 only opening the communication channel between the two. Similarly, a 600 firewall that permitted only encrypted tunnel traffic could be used 601 to secure a piece of a VPN. On the other hand, in that case the 602 other end of the VPN would need to be equally secured. 604 3.12. Kerberos 606 Kerberos [RFC1510] provides a mechanism for two entities to 607 authenticate each other and exchange keying material. On the client 608 side, an application obtains a Kerberos "ticket" and "authenticator". 609 These items, which should be considered opaque data, are then 610 communicated from client to server. The server can then verify their 611 authenticity. Both sides may then ask the Kerberos software to 612 provide them with a session key which can be used to protect or 613 encrypt data. 615 Kerberos may be used by itself in a protocol. However, it is also 616 available as a mechanism under SASL and GSSAPI. It has some known 617 vulnerabilities [KRBATTACK] [KRBLIM] [KRB4WEAK], but it can be used 618 securely. 620 3.13. SSH 622 SSH provides a secure connection between client and server. It 623 operates very much like TLS; however, it is optimized as a protocol 624 for remote connections on terminal-like devices. One of its more 625 innovative features is its support for "tunneling" other protocols 626 over the SSH-protected TCP connection. This feature has permitted 627 knowledgeable security people to perform such actions as reading and 628 sending e-mail or news via insecure servers over an insecure network. 629 It is not a substitute for a true VPN, but it can often be used in 630 place of one. 632 4. Insecurity Mechanisms 634 Some common security mechanisms are part of the problem rather than 635 part of the solution. 637 4.1. Plaintext Passwords 639 Plaintext passwords are the most common security mechanism in use 640 today. Unfortunately, they are also the weakest. When not protected 641 by an encryption layer, they are completely unacceptable. Even when 642 used with encryption, plaintext passwords are quite weak, since they 643 must be transmitted to the remote system. If that system has been 644 compromised or if the encryption layer does not include effective 645 authentication of the server to the client, an enemy can collect the 646 passwords and possibly use them against other targets. 648 Another weakness arises because of common implementation techniques. 649 It is considered good form [MT79] for the host to store a one-way 650 hash of the users' passwords, rather than their plaintext form. 651 However, that may preclude migrating to stronger authentication 652 mechanisms, such as HMAC-based challenge/response. 654 The strongest attack against passwords, other than eavesdropping, is 655 password-guessing. With a suitable program and dictionary (and these 656 are widely available), 20-30% of passwords can be guessed in most 657 environments [Klein90]. 659 4.2. Address-Based Authentication 661 Another common security mechanism is address-based authentication. 662 At best, it can work in highly constrained environments. If your 663 environment consists of a small number of machines, all tightly 664 administered, secure systems run by trusted users, and if the network 665 is guarded by a router that blocks source-routing and prevents 666 spoofing of your source addresses, and you know there are no wireless 667 bridges, and if you restrict address-based authentication to machines 668 on that network, you are probably safe. But these conditions are 669 rarely met. 671 Among the threats are ARP-spoofing, abuse of local proxies, 672 renumbering, routing table corruption or attacks, DHCP, IP address 673 spoofing (a particular risk for UDP-based protocols), sequence number 674 guessing, and source-routed packets. All of these can be quite 675 potent. 677 4.3. Name-Based Authentication 679 Name-based authentication has all of the problems of address-based 680 authentication and adds new ones: attacks on the DNS [Bell95] and 681 lack of a one to one mapping between addresses and names. At a 682 minimum, a process that retrieves a host name from the DNS should 683 retrieve the corresponding address records and cross-check. 684 Techniques such as DNS cache contamination can often negate such 685 checks. 687 DNSSEC provides protection against this sort of attack. However, it 688 does nothing to enhance the reliability of the underlying address. 689 Further, the technique generates a lot of false alarms. These lookups 690 do not provide reliable information to a machine, though they might 691 be a useful debugging tool for humans and could be useful in logs 692 when trying to reconstruct how and attack took place. 694 5. Security Considerations 696 No security mechanisms are perfect. If nothing else, any network- 697 based security mechanism can be thwarted by compromise of the 698 endpoints. That said, each of the mechanisms described here has its 699 own limitations. Any decision to adopt a given mechanism should 700 weigh all of the possible failure modes. These in turn should be 701 weighed against the risks to the endpoint of a security failure. 703 6. IANA Considerations 705 There are no IANA considerations regarding this document. 707 7. Acknowledgements 709 Brian Carpenter, Tony Hain, and Marcus Leech made a number of useful 710 suggestions. Much of the substance comes from the participants in 711 the IAB Security Architecture Workshop. 713 8. Informative References 715 [Bell95] "Using the Domain Name System for System Break-Ins". Proc. 716 Fifth Usenix Security Conference, 1995. 718 [Bell98] "Cryptography and the Internet", S.M. Bellovin, in 719 Proceedings of CRYPTO '98, August 1998. 721 [DSS] "Digital Signature Standard". NIST. May 1994. 722 FIPS 186. 724 [Klein90] "'Foiling the Cracker': A Survey of, and Implications 725 to, Password Security". D. Klein. Usenix UNIX Security Workshop, 726 August 1990. 728 [KRBATTACK] "A Read-World Analysis of Kerberos Password 729 Security". T. Wu. Stanford University Computer Science Department, 730 http://theory.stanford.edu/~tjw/krbpass.html 732 [KRBLIM] "Limitations of the Kerberos Authentication System". 733 Proceedings of the 1991 Winter USENIX Conference, 1991. 735 [KRB4WEAK] "Misplaced trust: Kerberos 4 session keys". 736 Proceedings of the Internet Society Network and Distributed Systems 737 Security Symposium, March 1997. 739 [MT79] "UNIX Password Security", R.H. Morris and K. 740 Thompson, Communications of the ACM. November 1979. 742 [NATIKE] "Negotiation of NAT-Traversal in the IKE", T. Kivinen 743 et. al. Internet draft (work in progress) draft-ietf-ipsec-nat-t- 744 ike-03.txt, June 2002. 746 [RFC1321] "The MD5 Message-Digest Algorithm". R. Rivest. April 1992. 748 [RFC1750] "Randomness Recommendations for Security". D. Eastlake, 749 3rd, S. Crocker & J. Schiller. December 1994. 751 [RFC1847] "Security Multiparts for MIME: Multipart/Signed and 752 Multipart/Encrypted". J. Galvin, S. Murphy, S. Crocker & N. Freed. 753 October 1995. 755 [RFC2104] "HMAC: Keyed-Hashing for Message Authentication". H. 756 Krawczyk, M. Bellare, R. Canetti. February 1997. 758 [RFC2222] "Simple Authentication and Security Layer (SASL)". J. 759 Myers. October 1997. 761 [RFC2246] "The TLS Protocol Version 1.0". T. Dierks, C. Allen. 762 January 1999. 764 [RFC2289] "A One-Time Password System". N. Haller, C. Metz, P. 765 Nesser, M. Straw. February 1998. 767 [RFC2316] "Report of the IAB Security Architecture Workshop". S. 768 Bellovin. April 1998. 770 [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature 771 Option". A. Hefferman. August 1998. 773 [RFC2401] "Security Architecture for the Internet Protocol". S. Kent, 774 R. Atkinson. November 1998. 776 [RFC2402] "IP Authentication Header". S. Kent, R. Atkinson. November 777 1998. 779 [RFC2406] "IP Encapsulating Security Payload (ESP)". S. Kent, R. 780 Atkinson. November 1998. 782 [RFC2407] "The Internet IP Security Domain of Interpretation for 783 ISAKMP". D. Piper. November 1998. 785 [RFC2411] "IP Security Document Roadmap". R. Thayer, N. Doraswamy, R. 786 Glenn. November 1998. 788 [RFC2535] "Domain Name System Security Extensions". D. Eastlake. 789 March 1999. 791 [RFC2744] "Generic Security Service API Version 2 : C-bindings". J. 792 Wray. January 2000. 794 [RFC2993] "Architectural Implications of NAT". T. Hain. 795 November 2000. 797 [RFC3174] "US Secure Hash Algorithm 1 (SHA1)". D. Eastlake, 3rd, and 798 P. Jones. September 2001. 800 [RFC3261] "SIP: Session Initiation Protocol". Rosenberg et. al. 801 June 2002. 803 [RSA] "A Method for Obtaining Digital Signatures and 804 Public-Key Cryptosystems". R. Rivest, A. Shamir, L.M. Adleman, 805 Communications of the ACM, February 1978. 807 9. Author Information 809 This document is a publication of the Internet Architecture Board. 810 Internet Architecture Board Members at the time this document was 811 completed were: 813 Bernard Aboba 814 Harald Alvestrand 815 Rob Austein 816 Leslie Daigle, Chair 817 Patrik Faltstrom 818 Sally Floyd 819 Jun-ichiro Itojun Hagino 820 Mark Handley 821 Geoff Huston 822 Charlie Kaufman 823 James Kempf 824 Eric Rescorla 825 Michael StJohns 827 email: iab@iab.org 829 Steven M. Bellovin, Editor 830 email: smb@research.att.com 832 Jeffrey I. Schiller, Editor 833 email: jis@mit.edu 835 Charlie Kaufman, Editor 836 email: ckaufman@us.ibm.com 838 10. Intellectual Property Statement 840 The IETF takes no position regarding the validity or scope of any 841 intellectual property or other rights that might be claimed to 842 pertain to the implementation or use of the technology described in 843 this document or the extent to which any license under such rights 844 might or might not be available; neither does it represent that it 845 has made any effort to identify any such rights. Information on the 846 IETF's procedures with respect to rights in standards-track and 847 standards-related documentation can be found in BCP-11. Copies of 848 claims of rights made available for publication and any assurances of 849 licenses to be made available, or the result of an attempt made to 850 obtain a general license or permission for the use of such 851 proprietary rights by implementors or users of this specification can 852 be obtained from the IETF Secretariat. 854 The IETF invites any interested party to bring to its attention any 855 copyrights, patents or patent applications, or other proprietary 856 rights which may cover technology that may be required to practice 857 this standard. Please address the information to the IETF Executive 858 Director. 860 Full Copyright Statement 862 Copyright (C) The Internet Society (2003). All Rights Reserved. 864 This document and translations of it may be copied and furnished to 865 others, and derivative works that comment on or otherwise explain it 866 or assist in its implementation may be prepared, copied, published 867 and distributed, in whole or in part, without restriction of any 868 kind, provided that the above copyright notice and this paragraph are 869 included on all such copies and derivative works. However, this 870 document itself may not be modified in any way, such as by removing 871 the copyright notice or references to the Internet Society or other 872 Internet organizations, except as needed for the purpose of 873 developing Internet standards in which case the procedures for 874 copyrights defined in the Internet Standards process must be 875 followed, or as required to translate it into languages other than 876 English. 878 The limited permissions granted above are perpetual and will not be 879 revoked by the Internet Society or its successors or assignees. 881 This document and the information contained herein is provided on an 882 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 883 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 884 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 885 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 886 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 888 Acknowledgement 890 Funding for the RFC Editor function is currently provided by the 891 Internet Society.