RFC 3552
Guidelines for Writing RFC Text on Security Considerations
Guidelines for Writing RFC Text on Security Considerations 🎀
Okay bestie, here's the tea on this one 🫶 It's RFC 3552, filed as BCP 72 in the Best Current Practice category, and it came out in July 2003. The authors are E. Rescorla (RTFM, Inc.) and B. Korver (Xythos Software), and the Internet Architecture Board (IAB) is listed too. It's from the Network Working Group. Its header doesn't mention anything it obsoletes or updates, so there's no drama there 💅
Status of This Memo 📝
This document is an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements. You're free to distribute it, since distribution of this memo is unlimited ✨
Copyright Notice 🌸
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🦋
Every RFC has to include a Security Considerations section. Historically those sections have been pretty weak, honestly 🙈 So this document gives RFC authors guidelines for writing a good one, and we're going to level that up 🔥
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements. . . . . . . . . . . . . . . . . . . . . 3
2. The Goals of Security. . . . . . . . . . . . . . . . . . . 3
2.1. Communication Security. . . . . . . . . . . . . . . . 3
2.1.1. Confidentiality. . . . . . . . . . . . . . . . 4
2.1.2. Data Integrity . . . . . . . . . . . . . . . . 4
2.1.3. Peer Entity authentication . . . . . . . . . . 4
2.2. Non-Repudiation . . . . . . . . . . . . . . . . . . . 5
2.3. Systems Security. . . . . . . . . . . . . . . . . . . 5
2.3.1. Unauthorized Usage . . . . . . . . . . . . . . 6
2.3.2. Inappropriate Usage. . . . . . . . . . . . . . 6
2.3.3. Denial of Service. . . . . . . . . . . . . . . 6
3. The Internet Threat Model. . . . . . . . . . . . . . . . . 6
3.1. Limited Threat Models . . . . . . . . . . . . . . . . 7
3.2. Passive Attacks . . . . . . . . . . . . . . . . . . . 7
3.2.1. Confidentiality Violations . . . . . . . . . . 8
3.2.2. Password Sniffing. . . . . . . . . . . . . . . 8
3.2.3. Offline Cryptographic Attacks. . . . . . . . . 9
3.3. Active Attacks. . . . . . . . . . . . . . . . . . . . 9
3.3.1. Replay Attacks . . . . . . . . . . . . . . . . 10
3.3.2. Message Insertion. . . . . . . . . . . . . . . 10
3.3.3. Message Deletion . . . . . . . . . . . . . . . 11
3.3.4. Message Modification . . . . . . . . . . . . . 11
3.3.5. Man-In-The-Middle. . . . . . . . . . . . . . . 12
3.4. Topological Issues. . . . . . . . . . . . . . . . . . 12
3.5. On-path versus off-path . . . . . . . . . . . . . . . 13
3.6. Link-local. . . . . . . . . . . . . . . . . . . . . . 13
4. Common Issues. . . . . . . . . . . . . . . . . . . . . . . 13
4.1. User Authentication . . . . . . . . . . . . . . . . . 14
4.1.1. Username/Password. . . . . . . . . . . . . . . 14
4.1.2. Challenge Response and One Time Passwords. . . 14
4.1.3. Shared Keys. . . . . . . . . . . . . . . . . . 15
4.1.4. Key Distribution Centers . . . . . . . . . . . 15
4.1.5. Certificates . . . . . . . . . . . . . . . . . 15
4.1.6. Some Uncommon Systems. . . . . . . . . . . . . 15
4.1.7. Host Authentication. . . . . . . . . . . . . . 16
4.2. Generic Security Frameworks . . . . . . . . . . . . . 16
4.3. Non-repudiation . . . . . . . . . . . . . . . . . . . 17
4.4. Authorization vs. Authentication. . . . . . . . . . . 18
4.4.1. Access Control Lists . . . . . . . . . . . . . 18
4.4.2. Certificate Based Systems. . . . . . . . . . . 18
4.5. Providing Traffic Security. . . . . . . . . . . . . . 19
4.5.1. IPsec. . . . . . . . . . . . . . . . . . . . . 19
4.5.2. SSL/TLS. . . . . . . . . . . . . . . . . . . . 20
4.5.3. Remote Login . . . . . . . . . . . . . . . . . 22
4.6. Denial of Service Attacks and Countermeasures . . . . 22
4.6.1. Blind Denial of Service. . . . . . . . . . . . 23
4.6.2. Distributed Denial of Service. . . . . . . . . 23
4.6.3. Avoiding Denial of Service . . . . . . . . . . 24
4.6.4. Example: TCP SYN Floods. . . . . . . . . . . . 24
4.6.5. Example: Photuris. . . . . . . . . . . . . . . 25
4.7. Object vs. Channel Security . . . . . . . . . . . . . 25
4.8. Firewalls and Network Topology. . . . . . . . . . . . 26
5. Writing Security Considerations Sections . . . . . . . . . 26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. SMTP. . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.1. Security Considerations. . . . . . . . . . . . 29
6.1.2. Communications security issues . . . . . . . . 34
6.1.3. Denial of Service. . . . . . . . . . . . . . . 36
6.2. VRRP. . . . . . . . . . . . . . . . . . . . . . . . . .36
6.2.1. Security Considerations. . . . . . . . . . . . 36
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 38
8. Normative References . . . . . . . . . . . . . . . . . . . 39
9. Informative References . . . . . . . . . . . . . . . . . . 41
10.Security Considerations. . . . . . . . . . . . . . . . . . 42
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 43
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 441. Introduction ✨
Every RFC has to have a Security Considerations section, as required by RFC 2223 💖 The point is twofold: it nudges authors to think about security while they're designing, and it tells readers which security issues actually matter. This memo is here to help RFC authors hit both of those goals 🧚
The document is split into three parts. Part one is a mini security tutorial plus definitions of common terms. Part two is a set of guidelines for writing Security Considerations sections. Part three is a bunch of examples 🎀
1.1. Requirements
Here's how the requirement words work in this document 💜 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14, RFC 2119 [KEYWORDS].
2. The Goals of Security 🔐
Lots of people talk about security like it's one big solid property of a protocol or system. But if you think about it for two seconds, that's clearly not true 🙃 Security is actually a bunch of related properties that are kind of independent of each other. And not every one of them is needed for every application.
We can roughly split security goals into two buckets. One is protecting communications (COMMUNICATION SECURITY, also known as COMSEC). The other is protecting systems (ADMINISTRATIVE SECURITY or SYSTEM SECURITY) 🍓 These two totally interlock, since communications run on systems and you reach systems through communications channels. But they can also be provided on their own.
2.1. Communication Security 📡
Different authors split up the goals of communication security in different ways. The split that's worked best for this document is three major categories: CONFIDENTIALITY, DATA INTEGRITY and PEER ENTITY AUTHENTICATION 💅
2.1.1. Confidentiality 🤫
When most people think "security," they immediately think CONFIDENTIALITY, and honestly same. Confidentiality means your data is kept secret from people who aren't supposed to see it. Usually those people are just eavesdroppers. If an adversary taps your phone, that's a risk to your confidentiality 😭
Obviously, if you've got secrets, you're probably worried about other people finding them out. So at the very least, you want to keep things confidential. Remember when spies in movies run into the bathroom and crank on all the water to foil bugging? The property they're chasing there is confidentiality 💧
2.1.2. Data Integrity 🧾
The second big goal is DATA INTEGRITY. The core idea is that the data we receive should be the same data the sender actually sent 🎯 With paper, you get some integrity for free. If you get a letter written in pen, you can be pretty sure nobody removed any words, because pen marks are hard to erase from paper. But an attacker could still add some marks and totally change what the message says. And it's just as easy to chop the bottom off the page and truncate the message 🙈
Electronically it's way messier, because all bits look alike, so tampering with messages in transit is trivial 😬 An attacker can pull the message off the wire, copy out the bits they like, add whatever they want, and generate a brand new message, and the recipient is none the wiser. It's basically the paper version of someone copying your letter onto new stationery and quietly changing it while they recopy. Except it's way easier electronically, since all bits look alike 💀
2.1.3. Peer Entity authentication 🪪
The third property is PEER ENTITY AUTHENTICATION. This means we know that one of the endpoints in the communication is the one we meant to talk to 🦋 Without peer entity authentication, it's really hard to get either confidentiality or data integrity. Say we get a message from Alice. Data integrity doesn't do us much good unless we know it was really sent by Alice and not by the attacker. And if we want to send a confidential message to Bob, it's pointless if we're actually sending it to the attacker 😤
Peer entity authentication can be asymmetric, too 👑 When you call someone on the phone, you can be pretty sure you've got the right person, or at least someone who's actually at the phone number you dialed. But if they don't have caller ID, the person getting the call has no clue who's calling them. A phone call is an example of recipient authentication, since you know who you're reaching, but they don't know anything about you 📞
In messaging situations, you often want peer entity authentication to establish who sent a particular message. In that context, this property is called DATA ORIGIN AUTHENTICATION 🌈
2.2. Non-Repudiation 🎀
okay so bestie, an endpoint authentication system lets one party be totally sure who they're talking to 🫶 And when the system also gives you data integrity, the receiver can be sure of both who sent the message AND that they're getting exactly what the sender meant to send 💅 BUT here's the catch: they still can't necessarily prove any of that to a third party 😭 Being sure in your own head is not the same as being able to show it to someone else. The ability to make that demonstration is called NON-REPUDIATION ✨
Non-repudiation is SO desirable in lots of situations 💖 Picture two people who signed a contract, and then one of them wants to back out of it unilaterally. They could just go "lol I never signed that" 💀 Non-repudiation stops them from pulling that move, so the other party is protected 🛡️👑
Now the tea: non-repudiation is genuinely hard to pull off, and naive approaches usually don't cut it 🙈 Section 4.3 gets into the difficulties, and they mostly come down to this: the two parties don't want the same thing. One person wants to prove something, and the other person wants to deny it 😤 Opposite goals, big problems 🌸
2.3. Systems Security 🧚
okay, systems security is all about protecting your machines and your data 💜 The vibe is that machines should only be used by authorized users, and only for the stuff the owners actually intend ✨ Plus, they should be available for those purposes too 🍓 Attackers should NOT be able to lock legitimate users out of their own resources. That's a hard no 🙅♀️
2.3.1. Unauthorized Usage 🔐
most systems are not meant to be wide open to the public 🌈 They're meant for certain authorized people. Yes, lots of Internet services are open to everyone, but even those servers usually give a bigger set of services to specific users only 🫧 For example, Web Servers will often serve up data to anybody, but only certain users can change the pages 🖊️ If the general public tried to modify those pages, that would be UNAUTHORIZED USAGE 😤
2.3.2. Inappropriate Usage 🚫
being an authorized user doesn't mean you get free rein over the whole system, bestie 💅 Like we said above, some activities are limited to authorized users, some are limited to specific users, and some are basically off-limits for everyone except admins 🔧 And even stuff that's generally allowed can be forbidden in certain cases ✋ For example, a user might be allowed to send email, but NOT files over a certain size, or files that contain viruses 🦠 Those are all examples of INAPPROPRIATE USAGE 💀
2.3.3. Denial of Service 🌩️
remember our third goal? That the system should stay available to legitimate users 🥺 There's a whole bunch of attacks that threaten that, and they're collectively called DENIAL OF SERVICE attacks 😭 They're often super easy to launch and really hard to stop 💔 A lot of them are built to eat up machine resources, so it gets hard or even impossible to serve the real users 🫠 Other attacks just make the target machine crash, which totally shuts down service for everyone 💥
3. The Internet Threat Model 🕵️♀️
okay, so a THREAT MODEL describes what an attacker is assumed to be able to do against a resource ✨ It should cover things like how much info the attacker has, how much computing power they've got, and how much control they have over the system 🧠 A threat model has two jobs 🎯 First, we figure out which threats we actually care about. Second, we explicitly rule some threats out of scope 🙅♀️ Real talk: almost every security system is vulnerable to an attacker who is dedicated and resourceful enough 😩
The Internet has a pretty well understood threat model 📚 Generally, we assume the end-systems that are doing a protocol exchange have NOT been compromised 🖥️ Defending against an attack when one of the end-systems has been compromised is extraordinarily difficult 🥵 BUT it IS possible to design protocols that minimize how much damage gets done in that situation 🛠️✨
Now the other side of the coin 🪙 We assume the attacker has nearly complete control over the communications channel the end-systems are talking through 😱 That means the attacker can read any PDU (Protocol Data Unit) on the network, and can remove, change, or inject forged packets onto the wire WITHOUT anyone noticing 👀 They can even make packets that look like they came from a trusted machine 🎭 So even if the end-system you want to talk to is totally secure, the Internet gives you NO guarantee that packets claiming to come from that system actually do 🫠
It's important to realize that a PDU means different things at different layers 🧩 At the IP level, a PDU is an IP packet 📦 At the TCP level, it's a TCP segment 🧵 At the application layer, it's some kind of application PDU 💌 For example, at the email level, it might be an RFC-822 message or a single SMTP command 📧 At the HTTP level, it might be a request or a response 🌐
3.1. Limited Threat Models 📉
as we've said, a resourceful and dedicated attacker can control the whole communications channel 😈 BUT a lot of attacks can be pulled off by someone with way fewer resources 🙌 Plenty of known attacks only need an attacker with limited control of the network 🕸️ For instance, password sniffing attacks can be done by an attacker who can only read arbitrary packets 👂 This is generally called a PASSIVE ATTACK [INTAUTH] 👀
Meanwhile, Morris' sequence number guessing attack [SEQNUM] only needs an attacker who can write but not read arbitrary packets ✍️ Any attack that requires the attacker to write to the network is known as an ACTIVE ATTACK ⚡
So a super useful way to organize attacks is by sorting them based on what capabilities they need 🗂️ The rest of this section breaks down these categories and gives some examples of each one 💅
3.2. Passive Attacks 👂
in a passive attack, the attacker reads packets off the network but doesn't write any 🤫 The easiest way to pull this off is just being on the same LAN as the victim 🏠 On most common LAN setups, including Ethernet, 802.3, and FDDI, any machine on the wire can read ALL the traffic meant for any other machine on that same LAN 😳 Quick note though: switching hubs make this kind of sniffing way harder 🧱 Because traffic for a machine only goes to the network segment that machine is on 🙌
It's also similar when an attacker controls a host sitting in the communications path between two victim machines 🎯 They can passively attack the conversation that way 🫣 It's also possible to mess with the routing infrastructure so traffic gets routed through a compromised machine on purpose 🗺️ That might mean doing an active attack on the routing infrastructure to set up a passive attack on a victim 🪤
Wireless channels deserve special attention, especially with how popular wireless LANs are getting, like the ones using 802.11 📶 Since the data is basically just broadcast on well known radio frequencies, an attacker only needs to be able to receive those transmissions 📡 These channels are especially vulnerable to passive attacks 😬 Even though a lot of them include cryptographic protection, it's often so bad it's nearly useless [WEP] 🫠
Generally, the goal of a passive attack is to grab info the sender and receiver would rather keep private 🔒 That private stuff might include credentials useful in the electronic world, and/or passwords or credentials useful in the outside world, like confidential business info 💼
3.2.1. Confidentiality Violations 🫣
the classic passive attack is sniffing some inherently private data right off the wire 🎣 For example, even though SSL is widely available, lots of credit card transactions still travel across the Internet in the clear 💳 An attacker could sniff a message like that, get the credit card number, and then make fraudulent transactions 😭 And confidential business info gets sent over the network in the clear in email ALL the time 📨 Not it 🙅♀️
3.2.2. Password Sniffing 🔑
another passive attack example is PASSWORD SNIFFING 🫣 Password sniffing is aimed at getting unauthorized use of resources 🏴☠️ Lots of protocols, including [TELNET], [POP], and [NNTP], use a shared password to authenticate the client to the server 🤝 And a lot of the time, that password is sent from the client to the server in the clear over the channel 😱 So an attacker who can read this traffic can capture the password and REPLAY it 🔁 In other words, the attacker can open a connection to the server, pretend to be the client, and log in with the stolen password 🥷
Here's the thing: the login part of the attack is active, but the actual password capture is passive 🤓 Also, unless the server checks where connections are coming from, the login phase doesn't need any special network control at all 💅
3.2.3. Offline Cryptographic Attacks 🧮
lots of cryptographic protocols are vulnerable to OFFLINE ATTACKS 💻 In one of these, the attacker recovers data that was processed using the victim's secret key, and then runs a cryptanalytic attack on that key 🔓 Passwords are a especially juicy target because they're usually low entropy 🍬 A bunch of popular password-based challenge response protocols are vulnerable to a DICTIONARY ATTACK 📖 The attacker grabs a challenge-response pair and then just tries entries from a list of common words (like a dictionary file) until they find the password that gives the right response 🎯
A similar attack can happen on a local network when NIS is used 🏘️ The Unix password is crypted using a one-way function, but there are tools out there to break those crypted passwords [KLEIN] 🛠️ When NIS is used, the crypted password gets sent over the local network, so an attacker can sniff it and then attack it 😩
Historically, it's also been possible to exploit small operating system security holes to recover the password file using an active attack 🕳️ Those holes can then be bootstrapped into an actual account by using the offline password recovery techniques we just talked about 🪜 So basically, a low-level active attack gets combined with an offline passive attack 💥✨
3.3. Active Attacks
okay so when an attack involves writing data to the network, that's an ACTIVE ATTACK 💅 When IP runs without IPsec, nobody checks the sender address at all 🙈 So an attacker can just make a packet with whatever source address they want. That's a SPOOFING ATTACK 🎭
Sometimes the network catches it. Lots of packet filtering firewalls drop anything claiming an INTERNAL source address that shows up on the EXTERNAL interface 🛡️ But that does nothing about an attacker who's already inside the firewall 💀 So the rule is: designers should assume attackers can forge packets. Period 🫶
Here's the plot twist, though. Being able to forge packets doesn't mean you can receive arbitrary packets. There are active attacks where you send forged packets but never see the replies 👀 Those are called BLIND ATTACKS 🦋
Not every active attack needs a fake address either. The TCP SYN denial of service attack [TCPSYN] works fine with the attacker's real address 😭 Still, people usually fake their address anyway so they can hide who they are if the attack gets noticed 🕵️♀️
Every protocol has its own specific weak spots, but a bunch of common attack patterns work on basically any protocol 🌈 The next sections walk through those patterns and show real examples on known protocols ✨
3.3.1. Replay Attacks
In a REPLAY ATTACK, the attacker records a sequence of messages off the wire and plays them back to the party that originally got them 🔁 Here's the wild part: the attacker doesn't have to understand the messages at all 🙃 They just capture and resend.
Like, say an S/MIME message is requesting something important, like a credit card purchase or a stock trade 💳 An attacker could just want the service to run twice, honestly just to be annoying 😤 They capture the message, replay it, and boom, the transaction happens twice even though they can't read a single thing in it 💀
3.3.2. Message Insertion
In a MESSAGE INSERTION attack, the attacker forges a message with whatever properties they choose and injects it into the network 💉 Usually the message comes with a fake source address so nobody can tell who's really behind it 🎭
For example, a denial-of-service attack can be run by inserting a bunch of fake TCP SYN packets aimed at a target host 🎯 The target replies with its own SYN and sets aside kernel data structures for the new connection 🧠 The attacker never finishes the 3-way handshake, so those connection endpoints just sit there eating kernel memory 🍽️ Most TCP stacks only allow a limited number of these "half-open" connections, so once that limit is hit, nobody can start a new connection, not even legit hosts 😭 And this is a blind attack, since the attacker never has to process the victim's SYNs 🦋
3.3.3. Message Deletion
In a MESSAGE DELETION attack, the attacker removes a message from the wire 🗑️ Morris' sequence number guessing attack [SEQNUM] often needs a message deletion attack to actually work 🧩 In this blind attack, the host whose address is being forged gets a spurious TCP SYN from the host being attacked 😳 That SYN makes the host send a RST, which would tear down the fake connection 💔 So to stop that host from sending the RST, Morris describes flooding it to cause queue overflows, so the SYN gets dropped and never gets a response 🌊
3.3.4. Message Modification
In a MESSAGE MODIFICATION attack, the attacker pulls a message off the wire, changes it, and reinjects it into the network ✏️ This is extra useful when the attacker wants to keep some of the original data but swap out other parts 🔄
Imagine an attacker targeting an order for goods placed over the Internet 🛍️ They don't have the victim's credit card number, so they just wait for the victim to place the order, then swap the delivery address (and maybe the goods description) for their own 📦 This one has a name: a CUT-AND-PASTE attack, because the attacker cuts the credit card number out of the original message and pastes it into the new one ✂️📋
Another iconic cut-and-paste example is [IPSPPROB] 💅 If IPsec ESP runs without any MAC, the attacker can read traffic encrypted for a victim on the same machine 👀 They attach an IP header pointing at a port they control to the encrypted packet 🎀 When the host receives it, the packet gets decrypted and forwarded straight to the attacker's port 😱 Similar tricks can also pull off a session hijacking attack 🍓 Both attacks can be avoided by always using message authentication whenever you use encryption 🔐 This attack only works if (1) no MAC check is being used, since the attack creates damaged packets, and (2) a host-to-host SA is being used, since a user-to-user SA would cause an inconsistency between the port tied to the SA and the target port ⚠️ And if the receiving machine is single-user, this attack is infeasible 🙌
3.3.5. Man-In-The-Middle
A MAN-IN-THE-MIDDLE attack mixes the techniques above into one special combo 🍹 The attacker takes over the communication stream so they can pose as the sender to the receiver, and pose as the receiver to the sender 🕴️
What Alice and Bob think:
Alice <----------------------------------------------> Bob
What's happening:
Alice <----------------> Attacker <----------------> BobThis is a totally different beast from the attacks above, because it targets the identities of the communicating parties instead of the data stream itself 🪞 That's why plenty of techniques that protect stream integrity still aren't enough to stop man-in-the-middle attacks 😬
Man-in-the-middle attacks are possible whenever a protocol lacks PEER ENTITY AUTHENTICATION 🚨 For example, if an attacker can hijack the client's TCP connection during the TCP handshake (say, by answering the client's SYN before the server does), they can open another connection to the server and start a man-in-the-middle attack 🥷 It's also super easy to do this on local networks with ARP spoofing: the attacker forges an ARP with the victim's IP address and their own MAC address 📡 Tools for this are everywhere, sadly 😩
Here's the good news: you only need to authenticate one side of the transaction to stop man-in-the-middle attacks 🙌 In that setup, the peers can establish an association where only one peer is authenticated. An attacker can start an association pretending to be the unauthenticated peer, but they can't send or access data on a legit connection 🔒 This is totally fine in places like Web e-commerce, where only the server needs to be authenticated (or the client is authenticated some other non-cryptographic way, like a credit card number) 💖
3.4. Topological Issues
Okay, so the idea that an attacker can read and generate every packet equally easily is just not true 🙅♀️ The Internet isn't fully connected, so that assumption breaks down 🌐 This has two main consequences 👑
3.5. On-path versus off-path
For a datagram to get from one host to another, it usually has to pass through a bunch of intermediate links and gateways 🛤️ Those gateways can naturally read, modify, or remove any datagram that goes through them 😈 So if you're on-path, a huge range of attacks gets way easier 🔥
Off-path hosts can still send arbitrary datagrams that look like they came from anywhere 🎭 But they usually can't receive datagrams meant for other hosts 📭 So if an attack depends on receiving data, off-path hosts have to subvert the topology first to get themselves on-path 🧗♀️ That's not impossible, but it's not necessarily easy either 💅
Applications protocol designers MUST NOT assume that all attackers will be off-path. Where possible, protocols SHOULD be designed to resist attacks from attackers who have complete control of the network. However, designers are expected to give more weight to attacks which can be mounted by off-path attackers as well as on-path ones. 🚨
3.6. Link-local
One special case of on-path is being on the same link 🔗 Sometimes you want to tell apart hosts on your local network from hosts that aren't 👀 The standard way to do that is checking the IP TTL value [IP] ⏱️ Since every forwarder has to decrement the TTL, a protocol can require that TTL be set to 255 and that all receivers verify it ✅ Then a receiver has some reason to believe conforming packets are from the same link 🫶 Just be careful with this in the presence of tunneling systems, since they can pass packets along without decrementing TTL 🌀
4. Common Issues
Every system's security needs are unique, okay 🦋 But certain common requirements show up in a bunch of protocols 📋 And honestly, when naive protocol designers hit these requirements, they often grab an obvious but insecure solution even though better ones exist 😩 This section covers a bunch of issues that come up in tons of protocols, plus the common security tech that can help with them 🧰
4.1. User Authentication
Basically every system that wants to control access to its resources needs a way to authenticate users 🔑 There are an absolutely ridiculous number of mechanisms for this, like, nearly uncountable 🤯 The next few sections go through some of these techniques 💅
4.1.1. Username/Password
The most common access control mechanism is the classic USERNAME/PASSWORD 🔐 The user gives a username and a reusable password to the host they want to use 🖥️ The problem is that this is super vulnerable to a simple passive attack: the attacker sniffs the password off the wire and then starts a new session, presenting that same password 😭 You can mitigate this by running the protocol over an encrypted connection like TLS or IPSEC 🛡️ And plaintext username/password systems are just not acceptable in IETF standards 🚫💜
4.1.2. Challenge Response and One Time Passwords 🎟️
okay so systems that want more security than plain USERNAME/PASSWORD usually go with either a ONE TIME PASSWORD [OTP] scheme or a CHALLENGE-RESPONSE one 🔐. With one time passwords, the user gets a list of passwords that must be used in sequence, one time each. Often those passwords come from some secret key, so the user can just compute the next one in line 🧮. SecureID and DES Gold are variants of this scheme ✨.
In a challenge-response scheme, the host and the user share some secret (which is often a password) 🤫. To authenticate the user, the host shows them a randomly generated challenge 🎲. The user runs some function on the challenge and the secret, sends the result back to the host, and the host checks it ✅. This computation is often done on a handheld device, like a DES Gold card 💳.
Both types protect against replay attacks, but they're often still open to an OFFLINE KEYSEARCH ATTACK (a form of passive attack) 👀. As we said before, the one-time password or response is often computed from a shared secret. If the attacker knows the function, they can try every possible shared secret until one gives the right output 🕵️♀️. This is way easier when the shared secret is a password, because then they can run a DICTIONARY ATTACK, which means trying a list of common words (or strings) instead of just random strings 💀.
These systems are often vulnerable to active attacks too 😭. Unless communication security covers the entire session, the attacker can simply wait until authentication has happened and then hijack the connection 🦹.
4.1.3. Shared Keys 🗝️
CHALLENGE-RESPONSE systems can be made secure against dictionary attacks by using randomly generated shared keys instead of user-generated passwords 🙌. If the keys are big enough, keysearch attacks become impractical 🛡️. This works best when the keys are configured into the end nodes instead of being memorized and typed in by users, since users have trouble remembering keys that are long enough 🧠.
Like password-based systems, shared key systems have management problems too 🫠. Each pair of communicating parties must have their own agreed-upon key, which means there are a LOT of keys 😵💫.
4.1.4. Key Distribution Centers 🏢
One way to solve the too-many-keys problem is to use an online "trusted third party" that mediates between the authenticating parties 🤝. This trusted third party (generally called a KEY DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with each party in the system. A party first contacts the KDC, which gives it a TICKET containing a randomly generated symmetric key encrypted under both peers' keys 🎀. Since only the proper peers can decrypt that symmetric key, the ticket can be used to set up a trusted association 💞. By far the most popular KDC system is Kerberos [KERBEROS] 👑.
4.1.5. Certificates 📜
A simple approach is to have all users hold CERTIFICATES [PKIX], which they then use to authenticate in some protocol-specific way, like in [TLS] or [S/MIME] 💌. A certificate is a signed credential that binds an entity's identity to its public key 🪪. The signer of a certificate is a CERTIFICATE AUTHORITY (CA), and that CA's certificate may itself be signed by some superior CA 🪜. For this system to work, trust in one or more CAs must be established in an out-of-band fashion 🤞. Such CAs are called TRUSTED ROOTS or ROOT CAS 🌳. The main obstacle to this approach in client-server systems is that it requires clients to have certificates, which can be a deployment headache 😤.
4.1.6. Some Uncommon Systems 🦄
There are ways to do a better job than the schemes above, but they usually don't add much security unless communications security (at least message integrity) is used to protect the connection 🛡️. Otherwise, the attacker can just hijack the connection after authentication is done 🙅. A bunch of protocols ([EKE], [SPEKE], [SRP]) let you securely bootstrap a user's password into a shared key that can be used as input to a cryptographic protocol 🔑. One big obstacle to deploying these has been that their Intellectual Property status is super unclear ⚖️. Similarly, the user can authenticate using public key certificates (for example, S-HTTP client authentication) 📇. Usually these methods are part of a more complete security protocol 🫶.
4.1.7. Host Authentication 🖥️
Host authentication is a special problem 🚨. Pretty often, service addresses are given as a DNS hostname, for instance as a URL [URL]. When you request such a service, you have to make sure the entity you're talking to not only has a certificate, but that the certificate matches the expected identity of the server 🔍. The important thing is a secure binding between the certificate and the expected hostname 🔗.
For instance, it's usually not acceptable for the certificate to contain an identity in the form of an IP address if the request was for a given hostname 🙅♀️. This doesn't provide end-to-end security, because the hostname-IP mapping isn't secure unless secure name resolution [DNSSEC] is being used 🫣. This is a particular problem when the hostname shows up at the application layer but the authentication happens at some lower layer 😵💫.
4.2. Generic Security Frameworks 🧩
Providing security functionality in a protocol can be hard 😩. Besides picking authentication and key establishment mechanisms, you also need to integrate them into the protocol. One answer to this (embodied in IPsec and TLS) is to create a lower-level security protocol and then insist that new protocols run over it 🏗️. Another approach that has recently become popular is to design generic application layer security frameworks 🔌. The idea is that you design a protocol that lets you negotiate various security mechanisms in a pluggable way. Application protocol designers then carry the security protocol PDUs inside their application protocol 📦. Examples of these frameworks include GSS-API [GSS] and SASL [SASL] ✨.
The generic framework approach has a few problems. First, it's super susceptible to DOWNGRADE ATTACKS 📉. In a downgrade attack, an active attacker tampers with the negotiation to force the parties into weaker protection than they'd otherwise use 😈. It's possible to include an integrity check after the negotiation and key establishment have both completed, but the strength of that check is necessarily limited to the weakest common algorithm 🥲. This problem exists with any negotiation approach, but generic frameworks make it worse by encouraging application protocol authors to just specify the framework instead of thinking hard about the right underlying mechanisms, especially since mechanisms can vary widely in the degree of security they offer 🤷♀️.
Another problem is that it's not always obvious how the framework's security features interact with the application layer protocol 🤔. For instance, SASL can be used merely as an authentication framework, in which case the SASL exchange happens but the rest of the connection is unprotected. It can also negotiate traffic protection, such as via GSS, as a mechanism. Knowing under what circumstances traffic protection is optional and which is required takes thinking about the threat model 🧠.
In general, authentication frameworks are most useful in situations where new protocols are being added to systems with pre-existing legacy authentication systems 🏚️. A framework lets new installations provide better authentication without forcing existing sites to completely redo their legacy authentication systems 🎉. When the security requirements of a system can be clearly identified and only a few forms of authentication are used, choosing a single security mechanism leads to greater simplicity and predictability 💅. In situations where a framework is going to be used, designers SHOULD carefully examine the framework's options and specify only the mechanisms that are appropriate for their particular threat model 🔍. If a framework is necessary, designers SHOULD choose one of the established ones instead of designing their own 🫡.
4.3. Non-repudiation ✍️
The naive approach to non-repudiation is to simply use public-key digital signatures over the content 📝. The party who wishes to be bound (the SIGNING PARTY) digitally signs the message in question. The counterparty (the RELYING PARTY) can later point to the digital signature as proof that the signing party at one point agreed to the disputed message 📌. Unfortunately, this approach is insufficient 😬.
The easiest way for the signing party to repudiate the message (deny it) is to claim that their private key has been compromised and that some attacker (though not necessarily the relying party) signed the disputed message 🥷. To defend against this attack, the relying party needs to demonstrate that the signing party's key had not been compromised at the time of the signature. This requires substantial infrastructure, including archival storage of certificate revocation information and timestamp servers to establish the time the message was signed ⏰.
Additionally, the relying party might try to trick the signing party into signing one message while thinking they're signing another 🎭. This problem is especially severe when the relying party controls the infrastructure the signing party uses for signing, such as in kiosk situations. In many of these situations, the signing party's key is kept on a smartcard, but the message to be signed is displayed by the relying party 🖥️.
All of these complications make non-repudiation a difficult service to deploy in practice 💀.
4.4. Authorization vs. Authentication 🔑
AUTHORIZATION is the process by which one determines whether an authenticated party has permission to access a particular resource or service 🚪. Although they're tightly bound, it's important to realize that authentication and authorization are two separate mechanisms 🧩. Perhaps because of this tight coupling, authentication is sometimes mistakenly thought to imply authorization 🙃. Authentication simply identifies a party, while authorization defines whether they can perform a certain action ✅.
Authorization necessarily relies on authentication, but authentication alone does not imply authorization. Rather, before granting permission to perform an action, the authorization mechanism must be consulted to determine whether that action is permitted 🛂.
4.4.1. Access Control Lists 📋
One common form of authorization mechanism is an access control list (ACL), which lists the users that are permitted access to a resource 👯. Since assigning individual authorization permissions to each resource is tedious, resources are often hierarchically arranged so that the parent resource's ACL is inherited by child resources 🌲. This allows administrators to set top-level policies and override them when necessary 👑.
4.4.2. Certificate Based Systems
okay so the line between authentication and authorization is super intuitive with simple stuff like username and password 💅 (everyone gets that the admin account is not the same as a regular user account 🙈). but with fancier auth mechanisms it can get kinda blurry, bestie 🌸
with certificates, for instance, a valid signature does NOT automatically mean you're authorized ✨ the signature has to be backed by a certificate chain that contains a trusted root, and that root has to be trusted in the given context. like, users with certs from the Acme MIS CA might get different web access than users with certs from the Acme Accounting CA 🎀, even though the Acme web server "trusts" both CAs. iykyk 😭
figuring out how to enforce these more complicated properties is still kinda unexplored territory 🧚 one approach is to just attach policies to ACLs that describe which kinds of certificates are trusted 🦋. another approach is to carry that info inside the certificate itself, either as a certificate extension/attribute [PKIX, SPKI] or as a separate "Attribute Certificate" 💜
4.5. Providing Traffic Security
securely designed protocols should provide some way of securing all the sensitive traffic 🔥 (that means integrity protecting, authenticating, and possibly encrypting). one approach is to secure the protocol itself, like [DNSSEC], [S/MIME] or [S-HTTP] 🍓. it gives you security that's really tailored to the protocol, but it also takes a lot of effort to get right 💀
a bunch of protocols can be secured well enough using one of the existing channel security systems 🌈. the two most common are IPsec [AH, ESP] and [TLS] ⭐
4.5.1. IPsec
the IPsec protocols (specifically AH and ESP) can provide transmission security for all traffic between two hosts 🫶. they support different levels of user identification, like "IP Subnet", "IP Address", "Fully Qualified Domain Name", and individual users ("Mailbox name") 🦋. those levels get used as inputs to access control stuff that's built right into IPsec 👑. BUT a given IPsec implementation might not support every identity type 😬. especially, security gateways may not do user-to-user authentication or have a way to hand that auth info up to applications 💅
when AH or ESP is used, the app programmer might not need to do anything at all (if it's turned on system-wide) or might need to make specific software changes (like adding specific setsockopt() calls) 🌸, depending on the AH or ESP implementation. sadly, APIs for controlling IPsec implementations aren't standardized yet 😭
the main obstacle to using IPsec to secure other protocols is deployment 🙈. right now IPsec is mostly used for VPN stuff, especially remote network access 🔥. unless security admins and app developers are super tightly coordinated, VPN usage isn't great for securing individual apps, because it's hard for the app to figure out what security services were actually provided 💀
IPsec deployment in host-to-host environments has been slow 🐢. unlike app-level security systems like TLS, adding IPsec to a non-IPsec system usually means changing the operating system, either by modifying the kernel or installing new drivers 🛠️. that's a way bigger undertaking than just installing a new app 😤. however, recent versions of a bunch of commodity operating systems include IPsec stacks, so deployment is getting easier 🌈✨
IPsec is a viable option for protecting app traffic in environments where it's sure to be available 💖. if the traffic is UDP, then IPsec and application-specific object security are the only options 🦋. HOWEVER, designers MUST NOT assume IPsec will be available 🚫. a security policy for a generic application layer protocol SHOULD NOT just say IPsec must be used, unless there's some real reason to believe IPsec will be available in the intended deployment 🫶. in environments where IPsec might not be available and the traffic is solely TCP, TLS is the method of choice, since the app developer can easily guarantee it's there by including a TLS implementation in their package 🎀
in the special case of IPv6, both AH and ESP are MANDATORY to implement 👑. so it's reasonable to assume AH/ESP are already available for IPv6-only protocols or IPv6-only deployments ✨. BUT automatic key management (IKE) is NOT REQUIRED to implement, so protocol designers SHOULD not assume it'll be there 😭. [USEIPSEC] has a ton of guidance on when IPsec is a good choice 💜
4.5.2. SSL/TLS
right now the most common approach is SSL or its successor TLS 🔐. they provide channel security for a TCP connection at the application level, meaning they run over TCP 🧚. SSL implementations usually give you a Berkeley Sockets-like interface, which is super easy to program with 💅. the main issue when designing a protocol around TLS is telling apart connections protected by TLS from ones that aren't 🦋
the two main approaches are a separate well-known port for TLS connections (like HTTP over TLS on port 443) [HTTPTLS], or a mechanism for negotiating upward from the base protocol to TLS, as in [UPGRADE] or [STARTTLS] 🌸. with an upward negotiation strategy, you have to be careful that an attacker can NOT force a clear connection when both parties want TLS 🚨
TLS depends on a reliable protocol like TCP or SCTP 🫶. that causes two notable problems. first, it can't be used to secure datagram protocols that run over UDP 😭. second, TLS is vulnerable to IP layer attacks that IPsec isn't 💀. these usually look like denial of service or connection assassination 🗡️. for example, an attacker could forge a TCP RST to shut down SSL connections 🙈. TLS has ways to detect truncation attacks, but those only let the victim know they're being attacked, and don't keep the connection alive through the attack 😤. with IPsec, a forged RST could be rejected without affecting the TCP connection at all 🛡️✨. if forged RSTs or other attacks on the TCP connection are a concern, then AH/ESP or the TCP MD5 option [TCPMD5] are the preferred choices 👑
4.5.2.1. Virtual Hosts
if the "separate ports" approach to TLS is used, TLS gets negotiated before any application-layer traffic is sent 🌸. this can cause a problem for protocols that use virtual hosts, like [HTTP], because the server doesn't know which certificate to offer the client during the TLS handshake 😭. the TLS hostname extension [TLSEXT] can solve this, although it's too new to have seen wide deployment 🍓
4.5.2.2. Remote Authentication and TLS
one difficulty with TLS is that the server is authenticated via a certificate 📜. that can be a hassle in environments where the only auth used to be a password shared between client and server 🙃. it's tempting to use TLS without an authenticated server (i.e., with anonymous DH or a self-signed RSA certificate) and then authenticate with some challenge-response mechanism like SASL with CRAM-MD5 🫣. but this composition of SASL and TLS is way weaker than you'd expect 🚨. it's easy for an active attacker to hijack the connection 😱. the client man-in-the-middles the SSL connection (remember, we're not authenticating the server, which is what normally stops this attack) and then just proxies the SASL handshake 🕵️. from then on, it's like the connection is in the clear, at least as far as that attacker is concerned 💀. to prevent this, the client NEEDS to verify the server's certificate 🔒
however, if the server IS authenticated, challenge-response becomes less desirable 🤔. if you already have a hardened channel, simple passwords are fine 💖. they're arguably better than challenge-response, since they don't require the password to be stored in the clear on the server ✨. so compromise of the key file with challenge-response systems is more serious than if simple passwords were used 😬
note that if the client has a certificate, SSL-based client authentication can be used 🎀. to make this easier, SASL provides the EXTERNAL mechanism, where the SASL client can tell the server "examine the outer channel for my identity" 🦋. obviously this isn't subject to the layering attacks described above 👑
4.5.3. Remote Login
sometimes it's worth providing channel-level security right in the application instead of using IPSEC or SSL/TLS 🧚. one such case is remote terminal security 💻. characters usually get sent from client to server one at a time 🔤. since SSL/TLS and AH/ESP authenticate and encrypt every packet, this can mean a data expansion of 20-fold 😱. the telnet encryption option [ENCOPT] avoids that expansion by giving up message integrity 🙈
when you're using remote terminal service, it's often nice to securely do other kinds of communication too 🌸. besides remote login, SSH [SSH] also does secure port forwarding for arbitrary TCP ports, so users can run arbitrary TCP-based apps over the SSH channel 🫶. note that SSH Port Forwarding can be a security issue if it's used improperly to get around firewalls or to expose insecure internal apps to the outside world 🚨
4.6. Denial of Service Attacks and Countermeasures
denial of service attacks get treated way too often like just a fact of life 😮💨. one problem is that an attacker can usually pick from tons of DoS attacks to hit a victim with, and since most of these can't be stopped, common wisdom says there's no point defending against one kind when there are a bunch of other DoS attacks that can't be prevented anyway 🙄
but not all DoS attacks are equal, and more importantly, protocols can be designed so DoS attacks are harder, if not impractical 🛡️✨. recent SYN flood attacks [TCPSYN] show both of these things: SYN floods are so easy, anonymous, and effective that they're more appealing to attackers than other attacks 🔥, and the design of TCP is what makes this attack possible 😭
because complete DoS protection is so hard, DoS security has to be handled pragmatically 🧠. some attacks that would be nice to defend against just can't be defended against economically 💸. the goal should be to manage risk by defending against attacks with a high enough ratio of severity to cost of defense 📊. both attack severity and cost of defense change as technology changes, so the set of attacks worth defending against changes too 🔄
authors of internet standards MUST describe which denial of service attacks their protocol is susceptible to 📝. this description MUST include the reasons it was either unreasonable or out of scope to try to avoid those DoS attacks 🙏💖
4.6.1. Blind Denial of Service
Okay so blind DoS attacks are honestly the most unhinged kind 😭 The attacker gets a big head start here. If the attacker needs to receive traffic from the victim, they have to either mess with the routing fabric or use their own IP address. Both of those give the victim a chance to track them down and/or filter out their traffic 🕵️♀️ But with a blind attack, the attacker can use forged IP addresses, which makes it super hard for the victim to filter out their packets. The TCP SYN flood is a perfect example of a blind attack 🙈 Designers really need to try their hardest to prevent blind denial of service attacks, bestie 💅
4.6.2. Distributed Denial of Service
Even scarier are DISTRIBUTED denial of service attacks (DDoS) [DDOS] 💀 In a DDoS, the attacker gets a bunch of machines to hit the target machine all at once. Usually they do this by infecting a huge number of machines with a program that lets the attacker start attacks remotely. The machines actually doing the attacking are called ZOMBIEs, and they're usually owned by unsuspecting third parties who are in a totally different location from the real attacker 😩 DDoS attacks are super hard to counter because the zombies often look like they're making totally legit protocol requests, and they just crowd out the real users. DDoS attacks can be tough to thwart, but protocol designers are expected to be aware of these forms of attack while they're designing protocols 🧠✨
4.6.3. Avoiding Denial of Service
There are two common approaches to making denial of service attacks more difficult 🎀
4.6.3.1. Make your attacker do more work than you do
If an attacker uses up more of their resources than yours when launching an attack, attackers with fewer resources than you won't be able to launch effective attacks 💪 One common technique is to make the attacker perform a time-intensive operation, like a cryptographic operation. Note that an attacker can still mount a denial of service attack if they can muster substantially sufficient CPU power 😤 For instance, this technique would not stop the distributed attacks described in [TCPSYN].
4.6.3.2. Make your attacker prove they can receive data from you
A blind attack can be subverted by forcing the attacker to prove that they can receive data from the victim 🦋 A common technique is to require that the attacker reply using information that was gained earlier in the message exchange. If this countermeasure is used, the attacker has to either use their own address (which makes them easy to track) or forge an address that will be routed back along a path that goes through the host the attack is being launched from.
Hosts on small subnets are kind of useless to the attacker (at least in the context of a spoofing attack) because the attack can be traced back to a subnet, which should be enough to locate the attacker 🔍 Then anti-attack measures can be put into place. For instance, a boundary router can be configured to drop all traffic from that subnet 🚫 A common technique is to require that the attacker reply using information that was gained earlier in the message exchange.
4.6.4. Example: TCP SYN Floods
TCP/IP is vulnerable to SYN flood attacks (which are described in section 3.3.2) because of the design of the 3-way handshake 🥺 First, an attacker can force a victim to use up a ton of resources (in this case, memory) by sending a single packet. Second, because the attacker can do this without ever receiving data from the victim, the attack can be carried out anonymously (and therefore with a large number of forged source addresses) 👻
4.6.5. Example: Photuris
[PHOTURIS] specifies an anti-clogging mechanism that prevents attacks on Photuris that look like the SYN flood attack. Photuris uses a time-variant secret to generate a "cookie," which is sent back to the attacker 🍪 This cookie must be returned in subsequent messages for the exchange to move forward. The iconic part is that the victim can regenerate this cookie later in the exchange, so no state needs to be kept by the victim until after the attacker has proven that they can receive packets from the victim 👑
4.7. Object vs. Channel Security
It's really useful to make the conceptual distinction between object security and channel security 🧁 Object security refers to security measures that apply to entire data objects. Channel security measures provide a secure channel over which objects can be carried transparently, but the channel has no special knowledge about object boundaries.
Let's look at an email message. When it's carried over an IPSEC or TLS secured connection, the message is protected during transmission. However, it's unprotected in the receiver's mailbox and in intermediate spool files along the way 📭 Moreover, since mail servers generally run as a daemon, not a user, authenticating messages generally just means authenticating the daemon, not the user 🤖 Finally, since mail transport is hop-by-hop, even if the user authenticates to the first hop relay, the receiver can't safely verify that authentication.
By contrast, when an email message is protected with S/MIME or OpenPGP, the entire message is encrypted and integrity protected until the recipient examines and decrypts it 🔐 It also provides strong authentication of the actual sender, as opposed to the machine the message came from. This is object security 💖 Moreover, the receiver can prove the signed message's authenticity to a third party 📜
Note that the difference between object and channel security is a matter of perspective. Object security at one layer of the protocol stack often looks like channel security at the next layer up 🪞 So, from the perspective of the IP layer, each packet looks like an individually secured object. But from the perspective of a web client, IPSEC just provides a secure channel 🌸
The distinction isn't always clear-cut 🫶 For example, S-HTTP provides object level security for a single HTTP transaction, but a web page typically consists of multiple HTTP transactions (the base page and numerous inline images). So, from the perspective of the whole web page, this looks a lot more like channel security. Object security for a web page would consist of security for the transitive closure of the page and all its embedded content as a single unit 🧩
4.8. Firewalls and Network Topology
It's a common security practice in modern networks to split the network into external and internal networks using a firewall 🧱 The internal network is then assumed to be secure, so only limited security measures are used there. The internal portion of such a network is often called a WALLED GARDEN 🏰
Internet protocol designers cannot safely assume their protocols will be deployed in such an environment, and here's why 👀 First, protocols that were originally designed to be deployed in closed environments often get deployed on the Internet later on, which creates serious vulnerabilities 😬
Second, networks that look topologically disconnected may not be. One reason is that the network may have been reconfigured to allow access from the outside world 🌐 Moreover, firewalls are increasingly passing generic application layer protocols such as [SOAP] or [HTTP]. Network protocols based on these generic protocols generally can't assume a firewall will protect them 🙅♀️ Finally, one of the most serious security threats to systems comes from insiders, not outsiders 😱 Since insiders by definition have access to the internal network, topological protections like firewalls won't protect them at all 🫠
5. Writing Security Considerations Sections ✨
okay bestie, not every protocol has to be bulletproof 🛡️ (nothing is immune to literally everything), BUT authors still gotta think about as many attack types as they possibly can 🧠. A big part of the Security Considerations section is spelling out which attacks are out of scope and which countermeasures can defend against the ones that are in scope 💅.
There should be a clear description of the kinds of threats on the described protocol or technology. Think of it as doing your due diligence 📚, listing every known or foreseeable risk and threat for implementers and users. No skipping the scary stuff 😭.
Authors MUST describe 📝
- which attacks are out of scope (and why!)
- which attacks are in-scope
- 2.1 and the protocol is susceptible to
- 2.2 and the protocol protects against
At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle 🕵️♀️. Potential denial of service attacks MUST be identified as well 🙈. If the protocol incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.) 🔐. Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible to. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled 🤫.
If the technology involves authentication, particularly user-host authentication, the security of the authentication method MUST be clearly specified 🔑. That is, authors MUST document the assumptions that the security of this authentication method is predicated upon. For example, here's the vibe for the UNIX username/password login method:
Authentication in the system is secure only to the extent that it
is difficult to guess or obtain a ASCII password that is a maximum
of 8 characters long. These passwords can be obtained by sniffing
telnet sessions or by running the 'crack' program using the
contents of the /etc/passwd file. Attempts to protect against
on-line password guessing by (1) disconnecting after several
unsuccessful login attempts and (2) waiting between successive
password prompts is effective only to the extent that attackers
are impatient.
Because the /etc/passwd file maps usernames to user ids, groups,
etc. it must be world readable. In order to permit this usage but
make running crack more difficult, the file is often split into
/etc/passwd and a 'shadow' password file. The shadow file is not
world readable and contains the encrypted password. The regular
/etc/passwd file contains a dummy password in its place.It is insufficient to simply state that one's protocol should be run over some lower layer security protocol 🙅♀️. If a system relies upon lower layer security services for security, the protections those services are expected to provide MUST be clearly specified 📌. In addition, the resultant properties of the combined system need to be specified 🧩.
NOTE: In general, the IESG will not approve standards track protocols which do not provide for strong authentication, either internal to the protocol or through tight binding to a lower layer security protocol. 🚫
The threat environment addressed by the Security Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries 🌍, without assuming that firewalls are in place, even if only to provide justification for why such consideration is out of scope for the protocol. It is not acceptable to only discuss threats applicable to LANs and ignore the broader threat environment 💀. All IETF standards-track protocols are considered likely to have deployment in the global Internet. In some cases, there might be an Applicability Statement discouraging use of a technology or protocol in a particular environment. Nonetheless, the security issues of broader deployment should be discussed in the document 🎀.
There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed 🧾. Such risks might arise from compromise in a related protocol (e.g., IPsec is useless if key management has been compromised), from incorrect implementation, or from compromise of the security technology used for risk reduction (e.g., a cipher with a 40-bit key). There might also be risks that are not addressed by the protocol specification (e.g., denial of service attacks on an underlying link protocol). Particular care should be taken in situations where the compromise of a single system would compromise an entire protocol 🚨. For instance, in general protocol designers assume that end-systems are inviolate and don't worry about physical attack. However, in cases (such as a certificate authority) where compromise of a single system could lead to widespread compromises, it is appropriate to consider systems and physical security as well 🔒.
There should also be some discussion of potential security risks arising from potential misapplications of the protocol or technology described in the RFC 🙈. This might be coupled with an Applicability Statement for that RFC.
6. Examples 🎀
This section consists of some example security considerations sections, intended to give the reader a flavor of what's intended by this document ✨. The first example is a 'retrospective' example, applying the criteria of this document to an existing widely deployed protocol, SMTP 📧. The second example is a good security considerations section clipped from a current protocol 👑.
6.1. SMTP 💌
When RFC 821 was written, Security Considerations sections were not required in RFCs, and none is contained in that document 🙃. [RFC 2821] updated RFC 821 and added a detailed security considerations section. We reproduce here the Security Considerations section from that document (with new section numbers). Our comments are indented and prefaced with 'NOTE:'. We also add a number of new sections to cover topics we consider important. Those sections are marked with [NEW] in the section header 🦋.
6.1.1. Security Considerations 🔐
6.1.1.1. Mail Security and Spoofing 🎭
SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else 😬. Constructing such a message so that the "spoofed" behavior cannot be detected by an expert is somewhat more difficult, but not sufficiently so as to be a deterrent to someone who is determined and knowledgeable. Consequently, as knowledge of Internet mail increases, so does the knowledge that SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. Real mail security lies only in end-to-end methods involving the message bodies, such as those which use digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]) 💖.
NOTE: One bad approach to sender authentication is [IDENT] in which the receiving mail server contacts the alleged sender and asks for the username of the sender. This is a bad idea for a number of reasons, including but not limited to relaying, TCP connection hijacking, and simple lying by the origin server. Aside from the fact that IDENT is of low security value, use of IDENT by receiving sites can lead to operational problems. Many sending sites blackhole IDENT requests, thus causing mail to be held until the receiving server's IDENT request times out. 🙄
Various protocol extensions and configuration options that provide authentication at the transport level (e.g., from an SMTP client to an SMTP server) improve somewhat on the traditional situation described above. However, unless they are accompanied by careful handoffs of responsibility in a carefully-designed trust environment, they remain inherently weaker than end-to-end mechanisms which use digitally signed messages rather than depending on the integrity of the transport system 🧐.
Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided 🚫: they frustrate legitimate applications in which mail is sent by one user on behalf of another, or in which error (or normal) replies should be directed to a special address. (Systems that provide convenient ways for users to alter these fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender fields within the message data can be generated sensibly 🌸.)
This specification does not further address the authentication issues associated with SMTP other than to advocate that useful functionality not be disabled in the hope of providing some small margin of protection against an ignorant user who is trying to fake mail 🙅♀️.
NOTE: We have added additional material on communications security and SMTP in Section 6.1.2. In a final specification, the above text would be edited somewhat to reflect that fact. 🧚
6.1.1.2. Blind Copies 🙊
Addresses that do not appear in the message headers may appear in the RCPT commands to an SMTP server for a number of reasons. The two most common involve the use of a mailing address as a "list exploder" (a single address that resolves into multiple addresses) and the appearance of "blind copies" 📬. Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the headers, either as part of trace headers or as informational or private-extension headers. Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command 🍓.
There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the headers. Receiving systems SHOULD NOT attempt to deduce such relationships and use them to alter the headers of the message for delivery 🕵️♀️. The popular "Apparently-to" header is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used 💅.
6.1.1.3. VRFY, EXPN, and Security
Okay so remember section 3.5? 🧐 Individual sites can totally turn off VRFY or EXPN (or both!) for security reasons 🔒. The flip side is that any implementation that lets you do that MUST NOT pretend to have verified addresses it never actually verified 🙅♀️. Lying about it is a hard no 💀. If a site disables these for security reasons, the SMTP server MUST return a 252 response, not a code that could be mistaken for a successful or unsuccessful verification 🎀.
Returning a 250 with the address from the VRFY command after only checking syntax breaks this rule 😭. And an implementation that "supports" VRFY by always replying 550, whether or not the address exists, is also not in conformance. Not it 💅.
Mailing lists have become a popular address buffet for "spammers" 🍽️ over the last few years. EXPN is getting used to "harvest" addresses as list admins add protections against inappropriate list use 🕵️♀️. Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs ⚖️. As authentication gets added to SMTP, some sites may only let authenticated requesters use EXPN 🔐.
NOTE: It's not clear that disabling VRFY adds much protection, since it's often possible to discover whether an address is valid using RCPT TO. 🙃
6.1.1.4. Information Disclosure in Announcements
This one has been a debate forever 🗣️. On one side, announcing server type and version (and sometimes even the server domain name) in the greeting or in response to HELP is SO useful for debugging 🛠️, and nobody's denying that. On the other side, you're basically handing attackers info they could use 👀. The people who want it out there argue that it's way better to actually secure your SMTP server than to hope hiding its exact identity protects you from known vulnerabilities 🙄. Sites are encouraged to weigh the tradeoff with that in mind 💭. Implementations are strongly encouraged to minimally provide for making type and version information available to other network hosts 🫶.
6.1.1.5. Information Disclosure in Trace Fields
So, when mail comes from inside a LAN whose hosts aren't directly on the public Internet, trace ("Received") fields made under this spec can reveal host names and similar stuff that you'd normally never see 🕵️♀️. Usually that's not a big deal, but sites with special name-privacy concerns should be aware of it 📝. Also, the optional FOR clause should be supplied with caution or not at all when there are multiple recipients, lest it accidentally reveal who the "blind copy" recipients are to everyone else 🙈.
6.1.1.6. Information Disclosure in Message Forwarding
Remember section 3.4? Using the 251 or 551 reply codes to point at a mailbox's replacement address can accidentally leak sensitive info 📭. Sites that are worried about that should make sure they select and configure their servers appropriately ⚙️.
6.1.1.7. Scope of Operation of SMTP Servers
It's a well-established principle that an SMTP server can refuse mail for any operational or technical reason that makes sense to the site running it 🙅♀️. BUT cooperation between sites is what makes the Internet possible 🌐. If sites go overboard with rejecting traffic, the ubiquity of email (one of the Internet's best features 💌) gets threatened, so care and balance really matter if a site decides to be selective about the traffic it accepts and processes ⚖️.
In recent years, relaying through arbitrary sites has been used in hostile efforts to hide where mail actually came from 🥷. Some sites now limit relaying to known or identifiable sources, and implementations SHOULD provide the capability to do this kind of filtering 🧹. When mail gets rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate 📮.
6.1.1.8. Inappropriate Usage [NEW]
SMTP itself provides no protection against unsolicited commercial mass e-mail (aka spam) 😤. It's super hard to tell a priori whether a message is spam. From a protocol perspective, spam looks exactly like any other email... the difference is basically social and often pretty subtle 🫠. (Like, is a message from a merchant you've bought stuff from before advertising similar items spam? 🤔) SMTP spam-suppression is mostly about identifying known spam senders and either refusing to serve them or targeting them for punishment or disconnection 🚫. [RFC-2505] has loads of guidance on making SMTP servers spam-resistant, and we're just giving a quick overview here 📚.
The main tool for refusing spammers is the blacklist 🖤. An authority like [MAPS] collects and publishes a list of known spammers, and individual SMTP servers then block the blacklisted offenders (usually by IP address) 🧱.
Spammers try to hide who they are, either by just sending a false SMTP identity or by forwarding their mail through an Open Relay, which is an SMTP server that will relay mail for any sender 🎭. So there are now blacklists [ORBS] of open relays too 😵.
6.1.1.8.1. Closed Relaying [NEW]
To avoid being used for spam forwarding, lots of SMTP servers operate as closed relays 🔐, providing relaying only for clients they can identify. These relays should generally insist that senders advertise a sending address consistent with their known identity 🪪. If the relay is serving an identifiable network (like a corporate network or an ISP's network), then it's sufficient to block all other IP addresses. In other cases, explicit authentication must be used. The two standard choices are TLS [STARTTLS] and SASL [SASLSMTP] 🔑.
6.1.1.8.2. Endpoints [NEW]
Realistically, SMTP endpoints can't turn away unauthenticated senders 😩. Since the vast majority of senders are unauthenticated, doing that would break Internet mail interoperability 💔. The exception is when the endpoint server should only be receiving mail from some other server that can itself receive unauthenticated messages 🔁. For instance, a company might run a public gateway but configure its internal servers to only talk to that gateway 🏢.
6.1.2. Communications security issues [NEW]
Okay, SMTP itself provides no communications security 🙃, so a LOT of attacks are possible 💀. A passive attack is enough to recover the text of messages sent with SMTP 👂. No endpoint authentication is provided by the protocol. Sender spoofing is trivial, and therefore forging email messages is trivial too 🎭. Some implementations do add header lines with hostnames derived through reverse name resolution (which is only as secure as it is difficult to spoof DNS, and that's not very 😬). These header lines are normally not displayed to users, though. Receiver spoofing is also pretty straightforward, using either TCP connection hijacking or DNS spoofing 🪤. And since email often passes through SMTP gateways, all intermediate gateways must be trusted, which is nearly impossible on the global Internet 🌍.
Several approaches are available for easing these threats. In order of increasingly high level in the protocol stack, we have:
SMTP over IPSECSMTP/TLSS/MIME and PGP/MIME
6.1.2.1. SMTP over IPSEC [NEW]
An SMTP connection run over IPSEC can provide confidentiality for the message between the sender and the first hop SMTP gateway, or between any pair of connected SMTP gateways 🔒. That's to say, it's channel security for the SMTP connections. When the message goes directly from the client to the receiver's gateway, this may provide substantial security (though the receiver still has to trust the gateway 🫣). Protection is provided against replay attacks, since the data itself is protected and the packets cannot be replayed 🔁.
Endpoint identification is a problem, though, unless the receiver's address can be directly cryptographically authenticated 😬. Sender identification isn't generally available, since usually only the sender's machine is authenticated, not the sender himself 🙄. Plus, the sender's identity just appears in the From header of the message, so the sender can easily spoof it 🎭. Finally, unless the security policy is set extremely strictly, there's also an active downgrade to cleartext attack 📉.
Another problem with IPsec as a security solution for SMTP is the lack of a standard IPsec API 🔌. To take advantage of IPsec, applications generally need to be able to tell the IPsec implementation about their security policies and find out what protection has been applied to their connections. Without a standard API, that's really hard to do portably 🧩.
Implementors of SMTP servers or SMTP administrators MUST NOT assume that IPsec will be available unless they have reason to believe that it will be (such as a preexisting association between two machines) 🚫. However, it may be a reasonable procedure to attempt to create an IPsec association opportunistically to a peer server when mail is delivered 🤞. Note that where IPsec is used to provide a VPN tunnel between two sites, this is of substantial security value, particularly to the extent that confidentiality is provided, subject to the caveats mentioned above 🏰. Also see [USEIPSEC] for general guidance on the applicability of IPsec ✨.
6.1.2.2. SMTP/TLS [NEW]
SMTP can be combined with TLS as described in [STARTTLS] 🔐. This provides similar protection to that provided when using IPSEC. Since TLS certificates typically contain the server's host name, recipient authentication may be slightly more obvious, but it's still susceptible to DNS spoofing attacks 🙃. Notably, common implementations of TLS contain a US exportable (and hence low security) mode 🇺🇸. Applications desiring high security should ensure that this mode is disabled ⚠️. Protection is provided against replay attacks, since the data itself is protected and the packets cannot be replayed 🔁.
[Note: The Security Considerations section of the SMTP over TLS document is quite good and bears reading as an example of how to do things.] 💖
6.1.2.3. S/MIME and PGP/MIME [NEW] 💌
okay bestie, S/MIME and PGP/MIME are both message-oriented security protocols 🎀 They wrap security around individual messages, which is called object security. With various settings you can get sender and recipient authentication and confidentiality. The big deal is that the identification isn't about the sending and receiving machines. It's about the actual sender and recipient themselves (or at least the cryptographic keys that belong to them 🔑). So end-to-end security can be obtained ✨ Note, though, that no protection is provided against replay attacks 💀 Also, S/MIME and PGP/MIME generally put identifying marks on both the sender and the receiver, so even when confidentiality is provided, traffic analysis is still possible 🙈
6.1.3. Denial of Service [NEW] 😭
None of these security measures gives any real protection against denial of service. SMTP connections can be used to tie up system resources in a bunch of ways 💅 That includes excessive port consumption, excessive disk usage (email is typically delivered to disk files), and excessive memory consumption (sendmail, for instance, is fairly large, and typically forks a new process to deal with each message.)
If transport- or application-layer security is used for SMTP connections, it's possible to mount a variety of attacks on individual connections using forged RSTs or other kinds of packet injection 👀
6.2. VRRP 🦋
The second example is from VRRP, the Virtual Router Redundance Protocol ([VRRP]). We reproduce the Security Considerations section from that document here (with new section numbers). Our comments are indented and prefaced with 'NOTE:'.
6.2.1. Security Considerations 🔐
VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods, ranging from no authentication, to simple clear text passwords, to strong authentication using IP Authentication with MD5 HMAC. The details on each approach, including possible attacks and recommended environments, follows.
Independent of any authentication type, VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks ✨
NOTE: The security measures discussed in the following sections only provide various kinds of authentication. No confidentiality is provided at all. This should be explicitly described as outside the scope.
6.2.1.1. No Authentication 🙃
With this authentication type, VRRP protocol exchanges are not authenticated. This type of authentication SHOULD only be used in environments were there is minimal security risk and little chance for configuration errors (e.g., two VRRP routers on a LAN).
6.2.1.2. Simple Text Password 🗝️
With this authentication type, VRRP protocol exchanges are authenticated by a simple clear text password.
This type of authentication is useful for protecting against accidental misconfiguration of routers on a LAN. It protects against routers inadvertently backing up another router. A new router must first be configured with the correct password before it can run VRRP with another router. It does not protect against hostile attacks, though, where the password can be learned by a node snooping VRRP packets on the LAN 👀 Simple Text Authentication combined with the TTL check makes it difficult for a VRRP packet to be sent from another LAN to disrupt VRRP operation.
This type of authentication is RECOMMENDED when there is minimal risk of nodes on a LAN actively disrupting VRRP operation. If you use this type of authentication, be aware that this clear text password is sent frequently, so it should not be the same as any security significant password 🚩
NOTE: This section should be clearer. The basic point is that no authentication and Simple Text are only useful for a very limited threat model, namely that none of the nodes on the local LAN are hostile. The TTL check prevents hostile nodes off-LAN from posing as valid nodes, but nothing stops hostile nodes on-LAN from impersonating authorized nodes. This is not a particularly realistic threat model in many situations. In particular, it's extremely brittle: the compromise of any node the LAN allows reconfiguration of the VRRP nodes.
6.2.1.3. IP Authentication Header 🛡️
With this authentication type, VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AH] using [HMAC]. This provides strong protection against configuration errors, replay attacks, and packet corruption/modification 💪
This type of authentication is RECOMMENDED when there is limited control over the administration of nodes on a LAN. While this type of authentication does protect the operation of VRRP, there are other types of attacks that may be employed on shared media links (e.g., generation of bogus ARP replies) which are independent from VRRP and are not protected 🙈
NOTE: It's a mistake to have AH be a RECOMMENDED in this context. Since AH is the only mechanism that protects VRRP against attack from other nodes on the same LAN, it should be a MUST for cases where there are untrusted nodes on the same network. In any case, AH should be a MUST implement.
NOTE: There's an important piece of security analysis that's only hinted at in this document, namely the cost/benefit tradeoff of VRRP authentication.
[The rest of this section is NEW material]
The threat that VRRP authentication is intended to prevent is an attacker arranging to be the VRRP master. This would be done by joining the group (probably multiple times), gagging the master, and then electing oneself master. Such a node could then direct traffic in arbitrary undesirable ways 😈
However, it is not necessary for an attacker to be the VRRP master to do this. An attacker can do similar kinds of damage to the network by forging ARP packets or (on switched networks) fooling the switch. VRRP authentication offers no real protection against these attacks.
Unfortunately, authentication makes VRRP networks very brittle in the face of misconfiguration. Consider what happens if two nodes are configured with different passwords. Each will reject messages from the other, and therefore both will attempt to be master. This creates substantial network instability 😭
This set of cost/benefit tradeoffs suggests that VRRP authentication is a bad idea, since the incremental security benefit is marginal but the incremental risk is high. This judgment should be revisited if the current set of non-VRRP threats are removed 🧐
7. Acknowledgments ✨
This document is heavily based on a note written by Ran Atkinson in 1997. That note was written after the IAB Security Workshop held in early 1997, based on input from everyone at that workshop 🫶 Some of the specific text above was taken from Ran's original document, and some of that text was taken from an email message written by Fred Baker. The other primary source for this document is specific comments received from Steve Bellovin. Early review of this document was done by Lisa Dusseault and Mark Schertler. Other useful comments were received from Bill Fenner, Ned Freed, Lawrence Greenfield, Steve Kent, Allison Mankin, and Kurt Zeilenga 💖
8. Normative References 📚
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[ENCOPT] Tso, T., "Telnet Data Encryption Option", RFC 2946, September, 2000.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[GSS] Linn, J., "Generic Security Services Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "HyperText Transfer Protocol", RFC 2616, June 1999.
[HTTPTLS] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[HMAC] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[OTP] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 "Public Key Infrastructure Certificate and Certificate Restoration List (CRL) Profile", RFC 3280, April 2002.
[RFC-2223] Postel J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC-2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC-2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SPKI] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[SSH] Ylonen, T., "SSH - Secure Login Connections Over the Internet", 6th USENIX Security Symposium, p. 37-42, July 1996.
[SASLSMTP] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[S-HTTP] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999.
[S/MIME] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D. and J. Mikkelsen, "Transport Layer Security (TLS) Extensions", RFC 3546, May 2003.
[TCPSYN] "TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory CA-1996-21, 19 September 1996, CERT. http://www.cert.org/advisories/CA-1996-21.html
[UPGRADE] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[URL] Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[VRRP] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M. and A. Lindemn, "Virtual Router Redundancy Protocol", RFC 2338, April 1998.
9. Informative References ✨
Okay, bestie, here's the reading list 📚💅 These are informative, not normative, so you don't need them to build anything, but they're the receipts behind the story.
- [DDOS] "Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28 December 1999, CERT http://www.cert.org/advisories/CA-1999-17.html
- [EKE] Bellovin, S., Merritt, M., "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992.
- [IDENT] St. Johns, M. and M. Rose, "Identification Protocol", RFC 1414, February 1993.
- [INTAUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
- [IPSPPROB] Bellovin, S. M., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix UNIX Security Symposium, July 1996.
- [KLEIN] Klein, D.V., "Foiling the Cracker: A Survey of and Improvements to Password Security", 1990.
- [NNTP] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
- [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
- [SEQNUM] Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP Software", AT&T Bell Laboratories, CSTR 117, 1985.
- [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D., "Simple Object Access Protocol (SOAP) 1.1", May 2000.
- [SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5, pp. 5-26, October 1996.
- [SRP] Wu T., "The Secure Remote Password Protocol", ISOC NDSS Symposium, 1998.
- [USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress.
- [WEP] Borisov, N., Goldberg, I., Wagner, D., "Intercepting Mobile Communications: The Insecurity of 802.11", http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf
10. Security Considerations 🔒
Okay, so this whole document is literally about security considerations 💀 The entire RFC is the security section, no cap. Take it seriously, bestie. 🫶
Appendix A.
IAB Members at the time of this writing
Harald Alvestrand
Ran Atkinson
Rob Austein
Fred Baker
Leslie Daigle
Steve Deering
Sally Floyd
Ted Hardie
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Mike St. JohnsAuthors' Addresses
Eric Rescorla
RTFM, Inc.
2439 Alvin Drive
Mountain View, CA 94043
Phone: (650)-320-8549
EMail: ekr@rtfm.com
Brian Korver
Xythos Software, Inc.
77 Maiden Lane, 6th Floor
San Francisco, CA, 94108
Phone: (415)-248-3800
EMail: briank@xythos.com
Internet Architecture Board
IAB
EMail: iab@iab.orgFull 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 assigns.
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: rfc3552 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms