RFC 3631
Security Mechanisms for the Internet
RFC 3631: Security Mechanisms for the Internet 🎀
Okay bestie, let's start with the header stuff 💅 This RFC was put together in the Network Working Group and dropped in December 2003. The editors are S. Bellovin, J. Schiller, and C. Kaufman (all "Ed."), with the Internet Architecture Board credited as well. It's Informational, so it's sharing info for the community and not setting an Internet standard. The header doesn't list anything it obsoletes or updates, so it's a clean slate 🌸
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. So basically, read it, share it, no gatekeeping 🦋
Copyright Notice 🔒
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 📝
Okay, the big picture ✨ Security has to be built into Internet protocols for those protocols to offer their services securely. A lot of security problems come from improper implementations. But even a perfectly implemented protocol will have security problems if the fundamental protocol is itself exploitable 💀 How security gets implemented in a protocol varies, because it depends on how that protocol is structured. Still, there are plenty of protocols where standard Internet security mechanisms that already exist might apply. The right one for any given situation can vary, so the doc reviews a bunch of different choices and explains the properties of each 🧚
1. Introduction ✨
Internet security compromises fall into several classes, ranging from Denial of Service all the way to Host Compromise 😭 Denial of Service attacks based on sheer volume of traffic are out of scope for this document, even though they're the subject of a ton of ongoing discussion and research. It's important to note that many of these attacks get harder with good security practices. Host Compromise (most commonly caused by undetected Buffer Overflows) represents flaws in individual implementations rather than flaws in protocols. Still, carefully designed protocols can make those flaws less likely to happen and harder to exploit 🫶
But there are also security compromises that the very protocols in use on the Internet make possible. If a security problem is inherent in a protocol, no implementation will be able to prevent it 🙈
So it's vitally important that protocols developed for the Internet provide this fundamental security. Full stop 🔥
How a protocol should be secured depends on the protocol itself and on its security needs. We've developed a number of standard security mechanisms in the IETF, though, and in many cases applying them properly can give a protocol the security it needs 💖
A number of possible mechanisms can provide security on the Internet, and which one you pick depends on lots of different factors. This document tries to give guidance by spelling out those factors, along with the currently-standardized (or about-to-be-standardized) solutions. These were discussed at the IAB Security Architecture Workshop [RFC2316] 🌈
Security, however, is an art, not a science. If you try to follow a recipe blindly, it can lead to disaster 😬 As always, good taste in protocol design should be exercised 👑
Finally, security mechanisms are not magic pixie dust you can sprinkle over finished protocols. It's rare that security can be bolted on later. Good designs (secure, clean, and efficient ones) happen when the security mechanisms are crafted alongside the protocol. No cryptography, however clever, can secure a protocol with flawed semantic assumptions 💅
2. Decision Factors 👑
2.1. Threat Model 🕵️
The most important factor in choosing a security mechanism is the threat model. That means asking who might be expected to attack what resource, and using what sorts of mechanisms. A low-value target, like a Web site that only offers public information, may not merit much protection. On the flip side, a resource that could expose significant parts of the Internet infrastructure if compromised (say, a major backbone router or a high-level Domain Name Server) should be protected by very strong mechanisms 🔥 The value of a target to an attacker depends on the purpose of the attack. If the goal is to access sensitive information, then every system that handles that information or mediates access to it is valuable. If the goal is to wreak havoc, systems that large parts of the Internet depend on are exceedingly 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's also hard, when designing a protocol, to predict what uses that protocol will someday have 🔮
All Internet-connected systems need a minimum amount of protection. Starting in 2000 and continuing to the present, we've watched a new kind of Internet security attack show up: an Internet "worm" program that seeks out and automatically attacks systems that are vulnerable to compromise through a number of attacks built into the worm program itself 😭 These worms can compromise literally thousands of systems in a very short period of time. Fun fact (well, not that fun): the first Internet Worm was the "Morris" worm of 1988. But it wasn't 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's not hard to imagine an attack that targets a fundamental security flaw in a widely deployed protocol. That's why it's imperative that we strive to minimize such flaws in the protocols we design 🫶
The value of a target to an attacker may also depend on where it's located. A network monitoring station that's physically on a backbone cable is a major target, since it could easily be turned into an eavesdropping station 👀 That same machine, if it sat on a stub net and was used for word processing, would be of much less use to a sophisticated attacker, and would therefore be at significantly less risk 🌸
We also have to consider what sorts of attacks to expect. At a minimum, eavesdropping must be seen as a serious threat, since there have been very many such incidents since at least 1993. Active attacks are often a risk too. These are attacks that involve inserting or deleting packets, and they 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." That's where someone on a link between two communicating parties waits for authentication to complete, then impersonates one of the parties and continues the connection with the other. Not me, not that 💀
One of the most important tools we have for securing protocols is cryptography ✨ It lets us 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 matters because the Internet, thanks to its distributed management and control, can't be considered a trustworthy medium in and of itself. Its security comes from the mechanisms we build into the protocols themselves, independent of the underlying media or network operators 🧚
Finally, of course, there's the cost to the defender of using cryptography. That 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 gets spread over too few transactions. Careful engineering design can generally let us spread that 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, than 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 🚀
2.2. A Word about Mandatory Mechanisms 🫶
We've evolved the notion of "mandatory to implement" mechanisms in the IETF. This philosophy comes from our main desire to ensure interoperability between different implementations of a protocol. If a protocol offers many options for how to perform a particular task but doesn't provide at least one that all implementations have to implement, multiple non-interoperable implementations may result 🙃 That's the consequence of different implementations deploying non-overlapping mechanisms.
Even though a given protocol may only use one or a few security mechanisms, those mechanisms can themselves often make use of several cryptographic systems. These cryptographic systems vary in strength and performance. Still, in many protocols we need to specify a "mandatory to implement" so that any two implementations can eventually negotiate a common cryptographic system between them 🤝
There are some protocols that were originally designed to run in a very limited domain. It's often argued that the domain of implementation for a particular protocol is sufficiently well defined and secure that the protocol itself doesn't need to provide any security mechanisms 🙄
History has shown this argument to be wrong. Successful protocols, even ones developed for limited use, inevitably wind up used in a broader environment where the initial security assumptions don't hold 😭
So 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's important to understand that mandatory mechanisms are mandatory to implement. It's not necessarily mandatory that end-users actually use them. If an end-user knows they're deploying a protocol over a "secure" network, they may choose to disable security mechanisms that they believe add insufficient value compared to their performance cost. (We're generally skeptical of the wisdom of disabling strong security even then, but that's beyond the scope of this document 🙈)
Insisting that certain mechanisms are mandatory to implement means that the end-users who need the protocol's security mechanism have it available when they need it. Particularly with security mechanisms, though, just because a mechanism is mandatory to implement doesn't mean it should be the default mechanism, or that it may not be disabled by configuration. And if a mandatory to implement algorithm is old and weak, it's better to disable it when a stronger algorithm is available 🔥
2.3. Granularity of Protection ✨
okay so security mechanisms can protect a whole network 🏰 which is lowkey efficient because you don't need a bunch of hardware, BUT it can leave the inside of the network wide open to attacks from the inside 😬. Other mechanisms can protect down to the individual user of a timeshared machine 👤, though if that machine has been compromised, someone could literally impersonate a user 💀.
when you're figuring out how granular your protection should be, protocol designers need to think about likely usage patterns, implementation layers (more on that below), and deployability 📋. if a protocol is only ever going to be used from inside a secure cluster of machines (like a Network Operations Center, say), subnet granularity might be the move 🎯. but a security mechanism that's specific to one single application is best built into that application and NOT inside TCP 🚫, because otherwise deployment is gonna be a total nightmare 😭.
2.4. Implementation Layer 🧱
security mechanisms can live at any layer, bestie 💅. generally, putting a mechanism at a lower layer protects a wider variety of higher-layer protocols, but it might not protect them as well 🤔. like, a link-layer encryptor can protect not just IP but even ARP packets 🙈. the catch is that its reach is just that one link 🔗.
flip it around and you get a signed email message 💌. that one is protected even when it's sent through a bunch of store-and-forward mail gateways 📬, it can identify the actual sender 🕵️♀️, and the signature can be verified long after the message has been delivered 🗓️. the tea though is that only that one type of message is protected. messages with similar formats, like some Netnews postings, are NOT protected unless the mechanism is specifically adapted and then implemented in the news-handling programs 📰.
3. Standard Security Mechanisms 🛡️
3.1. One-Time Passwords 🔑
one-time password schemes, like the one described in [RFC2289], are so much stronger than conventional passwords 💪. the host doesn't need to store a copy of the user's password, and it's never sent over the network either 🙌. but ngl there are some risks 😬. since the string that gets sent is derived from a user-typed password, guessing attacks might still be feasible 🎲. (and yes, a program to launch just this attack is readily available 💀.) also, the user's ability to log in expires after a predetermined number of uses 🥀. in lots of cases that's actually a feature ✨, but an implementation most likely needs a way to reinitialize the authentication database WITHOUT sending the new password in the clear across the network 🔒.
there are commercial hardware authentication tokens too 🪙. besides the session hijacking issue, supporting these tokens (especially challenge/response tokens, where the server sends a different random number for each authentication attempt) may need extra protocol messages 📨.
3.2. HMAC 🧁
HMAC [RFC2104] is the preferred shared-secret authentication technique 👑. if both sides know the same secret key, HMAC can authenticate any arbitrary message 🫶. that includes random challenges, which means HMAC can be adapted to prevent replays of old sessions 🔁.
the unfortunate downside of using HMAC for connection authentication is that the secret has to be known in the clear by BOTH parties 😩. that makes it undesirable when keys are long-lived ⏳.
when it's suitable, HMAC should be used instead of older techniques, especially keyed hash functions 🙅♀️. simple keyed hashes based on MD5 [RFC1321], like the one used in the BGP session security mechanism [RFC2385], are especially to be avoided in new protocols, given the hints of weakness in MD5 🚩. big nope 💀.
HMAC can be implemented using any secure hash function, including MD5 and SHA-1 [RFC3174] 🧩. SHA-1 is preferable for new protocols because it's more frequently used for this purpose and may be more secure 🔐.
⚠️ it's super important to understand that an HMAC-based mechanism needs to be employed on EVERY protocol data unit (aka packet) 💥. it's 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 🙅♀️.
and this is the scary part 😱: attack programs exist that permit a TCP session to be stolen 🏴☠️. an attacker just needs to use such a tool to steal a session after the HMAC step is performed 😭.
3.3. IPsec 🌐
IPsec [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 spec does permit user-granularity protection, but that's comparatively rare 🤷♀️. so IPsec is currently inappropriate when host-granularity is too coarse 🙅♀️.
because IPsec is installed at the IP layer, it's rather intrusive to the networking code 😤. implementing it generally needs either new hardware or a new protocol stack 🛠️. on the other hand, it's fairly transparent to applications ✨. applications running over IPsec can get improved security WITHOUT changing their protocols at all 🎉. but at least until IPsec is more widely deployed, most applications should not assume they're running atop IPsec as an alternative to specifying their own security mechanisms 🫠. most modern operating systems have IPsec available, but most routers don't, at least for the control path 🖥️. an application using TLS is more likely to be able to assert application-specific things 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 📜, though they may be more of a headache for the system manager 🤯.
there's strong potential for conflict between IPsec and NAT [RFC2993] 💔. NAT doesn't easily coexist with any protocol that contains embedded IP addresses 📍. with IPsec, every packet, for every protocol, contains such addresses, even if only in the headers 😵. the conflict can sometimes be avoided by using tunnel mode, but that's not always an appropriate choice for other reasons 🙃. there's ongoing work to make IPsec pass through NAT more easily [NATIKE] 🚧.
most current IPsec usage is for virtual private networks 🔒🏠. assuming 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 🧳.
3.4. TLS 🔏
TLS [RFC2246] provides an encrypted, authenticated channel that runs on top of TCP 🧵. while TLS was originally designed for use by Web browsers, it's by no means restricted to them 🌸. in general though, each application that wants to use TLS needs to be converted individually 🔧.
generally, the server side is always authenticated by a certificate 📜. clients may have certificates too, providing mutual authentication, though this is rarely deployed 🥲. it's an unfortunate reality that even server-side authentication isn't as secure in practice as the cryptography would imply 💀, because most implementations let users ignore authentication failures (by clicking OK to a warning) and most users routinely do so [Bell98] 🙈. so designers should be wary of demanding plaintext passwords, even over TLS-protected connections 🚨. (this requirement can be relaxed if it's likely that implementations will be able to verify the authenticity and authorization of the server's certificate ✅.)
although application modification is generally required to use 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 🎀.
3.5. SASL 🎭
SASL [RFC2222] is a framework for negotiating an authentication and encryption mechanism to be used over a TCP stream 🤝. as such, its security properties are those of the negotiated mechanism 🧐. specifically, unless the negotiated mechanism authenticates all of the subsequent messages, or an underlying protection protocol such as TLS is used, TCP connections are vulnerable to session stealing 😱.
okay but if you need to use TLS (or IPSec) under SASL, why even bother with SASL in the first place? 🤔 why not just use the authentication facilities of TLS and be done with it?
the answer is kinda 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, like passwords (one-time or otherwise) 🔑. a powerful combo is TLS for underlying protection and authentication of the server, plus a SASL-based system for authenticating clients 🫶. just be careful: you have to avoid man-in-the-middle vulnerabilities when different authentication techniques are used in different directions 🕳️.
3.6. GSS-API 🧩
GSS-API [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, so that must be evaluated independently 🧪. similar considerations apply to interoperability, of course 🤝.
3.7. DNSSEC 🌍
DNSSEC [RFC2535] digitally signs DNS records ✍️. it's 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 it wasn't widely deployed on the Internet at the time of writing 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 can be as simple as a service that's 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 standardizing the storing of keys for particular applications (IPsec in particular) is proceeding 🚀.
3.8. Security/Multipart 💌
Security/Multiparts [RFC1847] are the preferred mechanism for protecting email 📧. more precisely, it's 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 represent one form of "object security", where the object of interest to the end user is protected, independent of transport mechanism, intermediate storage, etc. 💅 ngl, there's currently no general form of object protection available on the Internet 😭.
for a good example of using S/MIME outside the context of email, see Session Initiation Protocol [RFC 3261] 🦋.
3.9. Digital Signatures 🖋️
okay so digital signatures are one of the strongest forms of challenge/response authentication, no cap 💅 Public key cryptography is way more iconic than secret key ciphers because no server ever needs a copy of the client's secret. The client keeps a private key, and servers only hold the matching public key. 🔐
BUT using digital signatures properly is lowkey tricky 😭 A client should never sign the exact challenge that was sent to it, because there are several subtle number-theoretic attacks that can get launched in that situation. Not it! 🙅♀️
The Digital Signature Standard [DSS] and RSA [RSA] are both solid picks, and each one has its own perks ✨ Signing with DSA needs good random numbers [RFC1750]. If the enemy can recover the random number used for any signature, or if you accidentally use the same random number for two different documents, your private key can be recovered. Yikes 💀 Performance-wise, DSS is way faster than RSA at generating new private keys and somewhat faster at generating signatures, while RSA is much faster at verifying signatures. Pick your fighter 🥊
3.10. OpenPGP and S/MIME 💌
okay this one is a whole saga 🎀 Digital signatures can be used to build "object security" applications, which protect data sitting in store and forward protocols like electronic mail.
At the time of writing, two secure mail protocols, OpenPGP [OpenPGP] and S/MIME [S/MIME], had been proposed to replace PEM [PEM]. It was not clear which one, if either, would win 👀 Even though both were specified for secure mail, either can be adapted to protect data carried by other protocols. Both use certificates to identify users, and both can provide secrecy and authentication of mail messages. The certificate formats, though, are very different 🙃 Historically, the big difference between PGP-based mail and S/MIME-based mail has been the style of certificate chaining. In S/MIME, users have X.509 certificates, and the certification graph is a tree with a very small number of roots. PGP, on the other hand, uses the so-called "web of trust," where any user can sign anyone else's certificate. That makes the certification graph a really arbitrary graph, or set of graphs 🕸️
With any certificate scheme, trust depends on two main things. First, it has to start from a known-reliable source: either an X.509 root, or someone the verifier highly trusts, which is often themselves. Second, the chain of signatures has to be reliable. Every node in the certification graph is crucial. If one is dishonest or has been compromised, every certificate it vouched for can't be trusted anymore. 😬 All other factors being equal (and they rarely are), shorter chains are preferable.
Some of the differences come from a tension between two philosophies these technologies represent. Others just came from having separate design teams 🧑💻
S/MIME is designed to be "fool proof," which means very little end-user configuration is needed. End-users don't have to be aware of trust relationships and all that jazz. The whole idea is that if an S/MIME client says, "This signature is valid," the user should be able to "trust" that statement at face value, without needing to understand what's happening underneath 🧁
To make that work, S/MIME is typically based on a limited number of "root" Certifying Authorities (CAs). The goal is to build a global trusted certificate infrastructure 🌍
The downside is that this approach needs a deployed public key infrastructure before it works at all. Two end-users may not be able to just grab S/MIME-capable software and start talking securely. This isn't a limitation of the protocol itself, just a typical configuration restriction for commonly available software. One or both of them may need to get a certificate from a mutually trusted CA, and that CA also has to already be trusted by their mail handling software. This can cost money and come with legal obligations. Ultimately, the technology is harder to deploy, especially in environments where end-users don't really appreciate the value they get for all the hassle 😩
PGP's "web of trust" has the advantage that two end-users can just get PGP software and immediately start communicating securely 🎉 No infrastructure is needed, and no fees or legal agreements need to be signed. That's why PGP appeals to people who need to set up ad-hoc security associations.
The downside to PGP is that end-users need to understand the underlying security technology to use it effectively. It's pretty easy to fool naive users into accepting a "signed" message that is actually a forgery 🙈
So far, PGP has found great acceptance among security-aware individuals who need secure e-mail in an environment without the necessary global infrastructure 🦋
S/MIME, by contrast, works well in a corporate setting where a secure internal CA system can be deployed. It doesn't require a lot of end-user security knowledge. S/MIME can also be used between institutions by carefully setting up cross certification, but that's harder to do than it sounds 😵💫
As of this writing, a global certificate infrastructure still hasn't happened. Questions about a suitable business model, plus privacy considerations, may keep one from ever emerging 🌫️
3.11. Firewalls and Topology 🧱
Firewalls are a topological defense mechanism. They rely on a well-defined boundary between the good "inside" and the bad "outside" of some domain, with the firewall mediating what information passes through. Firewalls can be super valuable if you use them properly, but they have limits on how well they can protect a network 🏰
The first limitation is that firewalls can't protect against inside attacks, obviously 🙄 The actual rate of these attacks isn't known (and is probably unknowable), but there's no doubt it's substantial, and arguably it makes up a majority of security problems. More generally, firewalls need a well-delimited boundary, so to the extent that a boundary doesn't exist, firewalls don't help. Any external connections weaken the protection. That includes protocols deliberately passed through the firewall, links that get tunneled through, unprotected wireless LANs, and direct external connections from hosts that are nominally on the inside. 🕳️ Firewalls also tend to get less effective over time as users tunnel protocols through them, and the tunnel endpoints may have inadequate security. If the tunnels are encrypted, the firewall has no way to censor them. People often say firewalls hide the existence of internal hosts from outside eyes, which is a plus, but given how much leaks out, the odds of successfully hiding machines are pretty low 👀
In a more subtle vein, firewalls hurt the end-to-end model of the Internet and its protocols 😤 Not every protocol can be passed safely or easily through a firewall. Sites that rely on firewalls for security may end up cut off from new and useful parts of the Internet.
Firewalls work best as one element of a total security structure 💖 For example, a strict firewall might separate an exposed Web server from a back-end database, with the only opening being the communication channel between the two. Similarly, a firewall that only permitted encrypted tunnel traffic could be used to secure part of a VPN. On the other hand, in that case the other end of the VPN would need to be equally secured 🔒
3.12. Kerberos 🎫
Kerberos [RFC1510] gives two entities a way to authenticate each other and exchange keying material. On the client side, an application gets a Kerberos "ticket" and "authenticator." These items should be treated as opaque data, and they get communicated from client to server, where the server can verify their authenticity. Then both sides can ask the Kerberos software for a session key to protect or encrypt data with 🗝️
Kerberos can be used by itself in a protocol. It's also available as a mechanism under SASL and GSSAPI. It has some known vulnerabilities [KRBATTACK] [KRBLIM] [KRB4WEAK], but it can still be used securely 🧚
3.13. SSH 🐚
SSH gives you a secure connection between client and server. It works very much like TLS, but it's optimized as a protocol for remote connections on terminal-like devices 💻 One of its most innovative features is support for "tunneling" other protocols over the SSH-protected TCP connection. This has let knowledgeable security people do things like read and send e-mail or news through insecure servers over an insecure network 🤯 It's not a substitute for a true VPN, but it can often be used in place of one 🌈
4. Insecurity Mechanisms 🚨
Some common security mechanisms are part of the problem rather than part of the solution. Oof 💀
4.1. Plaintext Passwords 🔑
Plaintext passwords are the most common security mechanism in use today, and unfortunately they're also the weakest 😭 If they aren't protected by an encryption layer, they're completely unacceptable. Even when encryption is used, plaintext passwords are still pretty weak, because they have to be transmitted to the remote system. If that system has been compromised, or if the encryption layer doesn't include effective authentication of the server to the client, an enemy can collect the passwords and possibly use them against other targets 👀
Another weakness comes from common implementation techniques. It's considered good form [MT79] for the host to store a one-way hash of users' passwords instead of their plaintext form. However, that may get in the way of 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] 🫠
4.2. Address-Based Authentication 📍
Another common security mechanism is address-based authentication. At best, it can work in highly constrained environments. If your environment consists of a small number of machines, all tightly administered, running secure systems operated by trusted users, and if the network is guarded by a router that blocks source-routing and prevents spoofing of your source addresses, and you know there are no wireless bridges, and you restrict address-based authentication to machines on that network, then you're probably safe. But these conditions are rarely met 🙃
Among the threats are ARP-spoofing, abuse of local proxies, renumbering, routing table corruption or attacks, DHCP, IP address spoofing (a particular risk for UDP-based protocols), sequence number guessing, and source-routed packets. All of these can be quite potent ⚠️
4.3. Name-Based Authentication ✨
okay so name-based auth has ALL the problems of address-based auth 😭 and then it adds its own new ones 💀. first, attacks on the DNS [Bell95], and second, there's no clean one-to-one mapping between addresses and names 🙈. the bare minimum is that a process which grabs a host name from the DNS should also fetch the matching address records and cross-check them 🧐. but techniques like DNS cache contamination can often cancel out that check 💔.
DNSSEC does protect you from this sort of attack 🛡️. HOWEVER, it does nothing to make the underlying address more reliable 🤷♀️. and the technique throws a LOT of false alarms 🚨. these lookups don't give a machine reliable info, though they could be a useful debugging tool for humans and handy in logs when you're trying to piece together how an attack took place 🕵️♀️🔍.
5. Security Considerations 🔐
no security mechanism is perfect, bestie 💅. at the very least, any network-based security mechanism can be thwarted if the endpoints get compromised 😱. that said, every mechanism in here has its own limitations 🧱. so before adopting any given one, weigh ALL of the possible failure modes ⚖️. and then weigh those against the risks to the endpoint if a security failure actually happens 🚨🫶.
6. IANA Considerations 🌸
there are no IANA considerations for this document, so nothing to register here ✨.
7. Acknowledgements 🫶
Brian Carpenter, Tony Hain, and Marcus Leech dropped a bunch of useful suggestions 💖. a lot of the substance comes from the participants in the IAB Security Architecture Workshop 🧚.
8. Informative References 📚
the reference list, exactly as written 📖:
[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.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RSA] Rivest, R., Shamir, A. and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, February 1978.9. Intellectual Property Statement ⚖️
the IETF takes no position on whether any intellectual property or other rights claimed to apply to the technology in this document are valid, how far they reach, or whether any license under them is available, and it doesn't claim to have tried to find any such rights 🤷♀️. info about the IETF's procedures for rights in standards-track and standards-related docs is in BCP-11 📖. copies of claims of rights made available for publication, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementors or users of this spec to use those proprietary rights can be obtained from the IETF Secretariat 📬.
the IETF also invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard 🫶. please send that info to the IETF Executive Director 💌.
10. Author Information 🧑💻
this document is a publication of the Internet Architecture Board 🏛️. the Internet Architecture Board members at the time this document was completed were 👑:
Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle, Chair
Patrik Faltstrom
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Michael StJohns
Internet Architecture Board
EMail: iab@iab.org
Steven M. Bellovin, Editor
EMail: bellovin@acm.org
Jeffrey I. Schiller, Editor
EMail: jis@mit.edu
Charlie Kaufman, Editor
EMail: charliek@microsoft.com11. Full Copyright Statement 📜
Copyright (C) The Internet Society (2003). All Rights Reserved. 🌈
this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works 💜. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English 🌍.
the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees ♾️.
this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙏.
Acknowledgement 🎀
funding for the RFC Editor function is currently provided by the Internet Society 💖.
📦 where this page comes from
- ietf: rfc3631 2003-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms