Request for Comments: 3552 RTFM, Inc.
BCP: 72 B. Korver
Category: Best Current Practice Xythos Software
Internet Architecture Board
IAB
July 2003
Guidelines for Writing RFCText on Security Considerations
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
All RFCs are required to have a Security Considerations section.
Historically, such sections have been relatively weak. This document
provides guidelines to RFCauthors on how to write a good Security
Considerations section.
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. . . . . . . . . . . . . . . . . . . 44
1. Introduction
All RFCs are required by RFC2223 to contain a Security
Considerations section. The purpose of this is both to encourage
document authors to consider security in their designs and to inform
the reader of relevant security issues. This memo is intended to
provide guidance to RFCauthors in service of both ends.
This document is structured in three parts. The first is a
combination security tutorial and definition of common terms; the
second is a series of guidelines for writing Security Considerations;
the third is a series of examples.
1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC2119
[KEYWORDS].
2. The Goals of Security
Most people speak of security as if it were a single monolithic
property of a protocol or system, however, upon reflection, one
realizes that it is clearly not true. Rather, security is a series
of related but somewhat independent properties. Not all of these
properties are required for every application.
We can loosely divide security goals into those related to protecting
communications (COMMUNICATION SECURITY, also known as COMSEC) and
those relating to protecting systems (ADMINISTRATIVE SECURITY or
SYSTEM SECURITY). Since communications are carried out by systems
and access to systems is through communications channels, these goals
obviously interlock, but they can also be independently provided.
2.1. Communication Security
Different authors partition the goals of communication security
differently. The partitioning we've found most useful is to divide
them into three major categories: CONFIDENTIALITY, DATA INTEGRITY and
PEER ENTITY AUTHENTICATION.
2.1.1. Confidentiality
When most people think of security, they think of CONFIDENTIALITY.
Confidentiality means that your data is kept secret from unintended
listeners. Usually, these listeners are simply eavesdroppers. When
an adversary taps your phone, it poses a risk to your
confidentiality.
Obviously, if you have secrets, then you are probably concerned about
others discovering them. Thus, at the very least, you want to
maintain confidentiality. When you see spies in the movies go into
the bathroom and turn on all the water to foil bugging, the property
they're looking for is confidentiality.
2.1.2. Data Integrity
The second primary goal is DATA INTEGRITY. The basic idea here is
that we want to make sure that the data we receive is the same data
that the sender has sent. In paper-based systems, some data
integrity comes automatically. When you receive a letter written in
pen you can be fairly certain that no words have been removed by an
attacker because pen marks are difficult to remove from paper.
However, an attacker could have easily added some marks to the paper
and completely changed the meaning of the message. Similarly, it's
easy to shorten the page to truncate the message.
On the other hand, in the electronic world, since all bits look
alike, it's trivial to tamper with messages in transit. You simply
remove the message from the wire, copy out the parts you like, add
whatever data you want, and generate a new message of your choosing,
and the recipient is no wiser. This is the moral equivalent of the
attacker taking a letter you wrote, buying some new paper and
recopying the message, changing it as he does it. It's just a lot
easier to do electronically since all bits look alike.
2.1.3. Peer Entity authentication
The third property we're concerned with is PEER ENTITY
AUTHENTICATION. What we mean by this is that we know that one of the
endpoints in the communication is the one we intended. Without peer
entity authentication, it's very difficult to provide either
confidentiality or data integrity. For instance, if we receive a
message from Alice, the property of data integrity doesn't do us much
good unless we know that it was in fact sent by Alice and not the
attacker. Similarly, if we want to send a confidential message to
Bob, it's not of much value to us if we're actually sending a
confidential message to the attacker.
Note that peer entity authentication can be provided asymmetrically.
When you call someone on the phone, you can be fairly certain that
you have the right person -- or at least that you got a person who's
actually at the phone number you called. On the other hand, if they
don't have caller ID, then the receiver of a phone call has no idea
who's calling them. Calling someone on the phone is an example of
recipient authentication, since you know who the recipient of the
call is, but they don't know anything about the sender.
In messaging situations, you often wish to use peer entity
authentication to establish the identity of the sender of a certain
message. In such contexts, this property is called DATA ORIGIN
AUTHENTICATION.
2.2. Non-Repudiation
A system that provides endpoint authentication allows one party to be
certain of the identity of someone with whom he is communicating.
When the system provides data integrity a receiver can be sure of
both the sender's identity and that he is receiving the data that
that sender meant to send. However, he cannot necessarily
demonstrate this fact to a third party. The ability to make this
demonstration is called NON-REPUDIATION.
There are many situations in which non-repudiation is desirable.
Consider the situation in which two parties have signed a contract
which one party wishes to unilaterally abrogate. He might simply
claim that he had never signed it in the first place. Non-
repudiation prevents him from doing so, thus protecting the
counterparty.
Unfortunately, non-repudiation can be very difficult to achieve in
practice and naive approaches are generally inadequate. Section 4.3
describes some of the difficulties, which generally stem from the
fact that the interests of the two parties are not aligned -- one
party wishes to prove something that the other party wishes to deny.
2.3. Systems Security
In general, systems security is concerned with protecting one's
machines and data. The intent is that machines should be used only
by authorized users and for the purposes that the owners intend.
Furthermore, they should be available for those purposes. Attackers
should not be able to deprive legitimate users of resources.
2.3.1. Unauthorized Usage
Most systems are not intended to be completely accessible to the
public. Rather, they are intended to be used only by certain
authorized individuals. Although many Internet services are
available to all Internet users, even those servers generally offer a
larger subset of services to specific users. For instance, Web
Servers often will serve data to any user, but restrict the ability
to modify pages to specific users. Such modifications by the general
public would be UNAUTHORIZED USAGE.
2.3.2. Inappropriate Usage
Being an authorized user does not mean that you have free run of the
system. As we said above, some activities are restricted to
authorized users, some to specific users, and some activities are
generally forbidden to all but administrators. Moreover, even
activities which are in general permitted might be forbidden in some
cases. For instance, users may be permitted to send email but
forbidden from sending files above a certain size, or files which
contain viruses. These are examples of INAPPROPRIATE USAGE.
2.3.3. Denial of Service
Recall that our third goal was that the system should be available to
legitimate users. A broad variety of attacks are possible which
threaten such usage. Such attacks are collectively referred to as
DENIAL OF SERVICE attacks. Denial of service attacks are often very
easy to mount and difficult to stop. Many such attacks are designed
to consume machine resources, making it difficult or impossible to
serve legitimate users. Other attacks cause the target machine to
crash, completely denying service to users.
3. The Internet Threat Model
A THREAT MODEL describes the capabilities that an attacker is assumed
to be able to deploy against a resource. It should contain such
information as the resources available to an attacker in terms of
information, computing capability, and control of the system. The
purpose of a threat model is twofold. First, we wish to identify the
threats we are concerned with. Second, we wish to rule some threats
explicitly out of scope. Nearly every security system is vulnerable
to a sufficiently dedicated and resourceful attacker.
The Internet environment has a fairly well understood threat model.
In general, we assume that the end-systems engaging in a protocol
exchange have not themselves been compromised. Protecting against an
attack when one of the end-systems has been compromised is
extraordinarily difficult. It is, however, possible to design
protocols which minimize the extent of the damage done under these
circumstances.
By contrast, we assume that the attacker has nearly complete control
of the communications channel over which the end-systems communicate.
This means that the attacker can read any PDU (Protocol Data Unit) on
the network and undetectably remove, change, or inject forged packets
onto the wire. This includes being able to generate packets that
appear to be from a trusted machine. Thus, even if the end-system
with which you wish to communicate is itself secure, the Internet
environment provides no assurance that packets which claim to be from
that system in fact are.
It's important to realize that the meaning of a PDU is different at
different levels. At the IP level, a PDU means an IP packet. At the
TCP level, it means a TCP segment. At the application layer, it
means some kind of application PDU. For instance, at the level of
email, it might either mean an RFC-822 message or a single SMTP
command. At the HTTP level, it might mean a request or response.
3.1. Limited Threat Models
As we've said, a resourceful and dedicated attacker can control the
entire communications channel. However, a large number of attacks
can be mounted by an attacker with fewer resources. A number of
currently known attacks can be mounted by an attacker with limited
control of the network. For instance, password sniffing attacks can
be mounted by an attacker who can only read arbitrary packets. This
is generally referred to as a PASSIVE ATTACK [INTAUTH].
By contrast, Morris' sequence number guessing attack [SEQNUM] can be
mounted by an attacker who can write but not read arbitrary packets.
Any attack which requires the attacker to write to the network is
known as an ACTIVE ATTACK.
Thus, a useful way of organizing attacks is to divide them based on
the capabilities required to mount the attack. The rest of this
section describes these categories and provides some examples of each
category.
3.2. Passive Attacks
In a passive attack, the attacker reads packets off the network but
does not write them. The simplest way to mount such an attack is to
simply be on the same LAN as the victim. On most common LAN
configurations, including Ethernet, 802.3, and FDDI, any machine on
the wire can read all traffic destined for any other machine on the
same LAN. Note that switching hubs make this sort of sniffing
substantially more difficult, since traffic destined for a machine
only goes to the network segment which that machine is on.
Similarly, an attacker who has control of a host in the
communications path between two victim machines is able to mount a
passive attack on their communications. It is also possible to
compromise the routing infrastructure to specifically arrange that
traffic passes through a compromised machine. This might involve an
active attack on the routing infrastructure to facilitate a passive
attack on a victim machine.
Wireless communications channels deserve special consideration,
especially with the recent and growing popularity of wireless-based
LANs, such as those using 802.11. Since the data is simply broadcast
on well known radio frequencies, an attacker simply needs to be able
to receive those transmissions. Such channels are especially
vulnerable to passive attacks. Although many such channels include
cryptographic protection, it is often of such poor quality as to be
nearly useless [WEP].
In general, the goal of a passive attack is to obtain information
which the sender and receiver would prefer to remain private. This
private information may include credentials useful in the electronic
world and/or passwords or credentials useful in the outside world,
such as confidential business information.
3.2.1. Confidentiality Violations
The classic example of passive attack is sniffing some inherently
private data off of the wire. For instance, despite the wide
availability of SSL, many credit card transactions still traverse the
Internet in the clear. An attacker could sniff such a message and
recover the credit card number, which can then be used to make
fraudulent transactions. Moreover, confidential business information
is routinely transmitted over the network in the clear in email.
3.2.2. Password Sniffing
Another example of a passive attack is PASSWORD SNIFFING. Password
sniffing is directed towards obtaining unauthorized use of resources.
Many protocols, including [TELNET], [POP], and [NNTP] use a shared
password to authenticate the client to the server. Frequently, this
password is transmitted from the client to the server in the clear
over the communications channel. An attacker who can read this
traffic can therefore capture the password and REPLAY it. In other
words, the attacker can initiate a connection to the server and pose
as the client and login using the captured password.
Note that although the login phase of the attack is active, the
actual password capture phase is passive. Moreover, unless the
server checks the originating address of connections, the login phase
does not require any special control of the network.
3.2.3. Offline Cryptographic Attacks
Many cryptographic protocols are subject to OFFLINE ATTACKS. In such
a protocol, the attacker recovers data which has been processed using
the victim's secret key and then mounts a cryptanalytic attack on
that key. Passwords make a particularly vulnerable target because
they are typically low entropy. A number of popular password-based
challenge response protocols are vulnerable to DICTIONARY ATTACK.
The attacker captures a challenge-response pair and then proceeds to
try entries from a list of common words (such as a dictionary file)
until he finds a password that produces the right response.
A similar such attack can be mounted on a local network when NIS is
used. The Unix password is crypted using a one-way function, but
tools exist to break such crypted passwords [KLEIN]. When NIS is
used, the crypted password is transmitted over the local network and
an attacker can thus sniff the password and attack it.
Historically, it has also been possible to exploit small operating
system security holes to recover the password file using an active
attack. These holes can then be bootstrapped into an actual account
by using the aforementioned offline password recovery techniques.
Thus we combine a low-level active attack with an offline passive
attack.
3.3. Active Attacks
When an attack involves writing data to the network, we refer to this
as an ACTIVE ATTACK. When IP is used without IPsec, there is no
authentication for the sender address. As a consequence, it's
straightforward for an attacker to create a packet with a source
address of his choosing. We'll refer to this as a SPOOFING ATTACK.
Under certain circumstances, such a packet may be screened out by the
network. For instance, many packet filtering firewalls screen out
all packets with source addresses on the INTERNAL network that arrive
on the EXTERNAL interface. Note, however, that this provides no
protection against an attacker who is inside the firewall. In
general, designers should assume that attackers can forge packets.
However, the ability to forge packets does not go hand in hand with
the ability to receive arbitrary packets. In fact, there are active
attacks that involve being able to send forged packets but not
receive the responses. We'll refer to these as BLIND ATTACKS.
Note that not all active attacks require forging addresses. For
instance, the TCP SYN denial of service attack [TCPSYN] can be
mounted successfully without disguising the sender's address.
However, it is common practice to disguise one's address in order to
conceal one's identity if an attack is discovered.
Each protocol is susceptible to specific active attacks, but
experience shows that a number of common patterns of attack can be
adapted to any given protocol. The next sections describe a number
of these patterns and give specific examples of them as applied to
known protocols.
3.3.1. Replay Attacks
In a REPLAY ATTACK, the attacker records a sequence of messages off
of the wire and plays them back to the party which originally
received them. Note that the attacker does not need to be able to
understand the messages. He merely needs to capture and retransmit
them.
For example, consider the case where an S/MIME message is being used
to request some service, such as a credit card purchase or a stock
trade. An attacker might wish to have the service executed twice, if
only to inconvenience the victim. He could capture the message and
replay it, even though he can't read it, causing the transaction to
be executed twice.
3.3.2. Message Insertion
In a MESSAGE INSERTION attack, the attacker forges a message with
some chosen set of properties and injects it into the network. Often
this message will have a forged source address in order to disguise
the identity of the attacker.
For example, a denial-of-service attack can be mounted by inserting a
series of spurious TCP SYN packets directed towards the target host.
The target host responds with its own SYN and allocates kernel data
structures for the new connection. The attacker never completes the
3-way handshake, so the allocated connection endpoints just sit there
taking up kernel memory. Typical TCP stack implementations only
allow some limited number of connections in this "half-open" state
and when this limit is reached, no more connections can be initiated,
even from legitimate hosts. Note that this attack is a blind attack,
since the attacker does not need 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
requires a message deletion attack to be performed successfully. In
this blind attack, the host whose address is being forged will
receive a spurious TCP SYN packet from the host being attacked.
Receipt of this SYN packet generates a RST, which would tear the
illegitimate connection down. In order to prevent this host from
sending a RST so that the attack can be carried out successfully,
Morris describes flooding this host to create queue overflows such
that the SYN packet is lost and thus never responded to.
3.3.4. Message Modification
In a MESSAGE MODIFICATION attack, the attacker removes a message from
the wire, modifies it, and reinjects it into the network. This sort
of attack is particularly useful if the attacker wants to send some
of the data in the message but also wants to change some of it.
Consider the case where the attacker wants to attack an order for
goods placed over the Internet. He doesn't have the victim's credit
card number so he waits for the victim to place the order and then
replaces the delivery address (and possibly the goods description)
with his own. Note that this particular attack is known as a CUT-
AND-PASTE attack since the attacker cuts the credit card number out
of the original message and pastes it into the new message.
Another interesting example of a cut-and-paste attack is provided by
[IPSPPROB]. If IPsec ESP is used without any MAC then it is possible
for the attacker to read traffic encrypted for a victim on the same
machine. The attacker attaches an IP header corresponding to a port
he controls onto the encrypted IP packet. When the packet is
received by the host it will automatically be decrypted and forwarded
to the attacker's port. Similar techniques can be used to mount a
session hijacking attack. Both of these attacks can be avoided by
always using message authentication when you use encryption. Note
that this attack only works if (1) no MAC check is being used, since
this attack generates damaged packets (2) a host-to-host SA is being
used, since a user-to-user SA will result in an inconsistency between
the port associated with the SA and the target port. If the
receiving machine is single-user than this attack is infeasible.
3.3.5. Man-In-The-Middle
A MAN-IN-THE-MIDDLE attack combines the above techniques in a special
form: The attacker subverts the communication stream in order to pose
as the sender to receiver and the receiver to the sender:
What Alice and Bob think:
Alice <----------------------------------------------> Bob
What's happening:
Alice <----------------> Attacker <----------------> Bob
This differs fundamentally from the above forms of attack because it
attacks the identity of the communicating parties, rather than the
data stream itself. Consequently, many techniques which provide
integrity of the communications stream are insufficient to protect
against man-in-the-middle attacks.
Man-in-the-middle attacks are possible whenever a protocol lacks PEER
ENTITY AUTHENTICATION. For instance, if an attacker can hijack the
client TCP connection during the TCP handshake (perhaps by responding
to the client's SYN before the server does), then the attacker can
open another connection to the server and begin a man-in-the-middle
attack. It is also trivial to mount man-in-the-middle attacks on
local networks via ARP spoofing -- the attacker forges an ARP with
the victim's IP address and his own MAC address. Tools to mount this
sort of attack are readily available.
Note that it is only necessary to authenticate one side of the
transaction in order to prevent man-in-the-middle attacks. In such a
situation the the peers can establish an association in which only
one peer is authenticated. In such a system, an attacker can
initiate an association posing as the unauthenticated peer but cannot
transmit or access data being sent on a legitimate connection. This
is an acceptable situation in contexts such as Web e-commerce where
only the server needs to be authenticated (or the client is
independently authenticated via some non-cryptographic mechanism such
as a credit card number).
3.4. Topological Issues
In practice, the assumption that it's equally easy for an attacker to
read and generate all packets is false, since the Internet is not
fully connected. This has two primary implications.
3.5. On-path versus off-path
In order for a datagram to be transmitted from one host to another,
it generally must traverse some set of intermediate links and
gateways. Such gateways are naturally able to read, modify, or
remove any datagram transmitted along that path. This makes it much
easier to mount a wide variety of attacks if you are on-path.
Off-path hosts can, of course, transmit arbitrary datagrams that
appear to come from any hosts but cannot necessarily receive
datagrams intended for other hosts. Thus, if an attack depends on
being able to receive data, off-path hosts must first subvert the
topology in order to place themselves on-path. This is by no means
impossible but is not necessarily trivial.
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 specialized case of on-path is being on the same link. In some
situations, it's desirable to distinguish between hosts who are on
the local network and those who are not. The standard technique for
this is verifying the IP TTL value [IP]. Since the TTL must be
decremented by each forwarder, a protocol can demand that TTL be set
to 255 and that all receivers verify the TTL. A receiver then has
some reason to believe that conforming packets are from the same
link. Note that this technique must be used with care in the
presence of tunneling systems, since such systems may pass packets
without decrementing TTL.
4. Common Issues
Although each system's security requirements are unique, certain
common requirements appear in a number of protocols. Often, when
naive protocol designers are faced with these requirements, they
choose an obvious but insecure solution even though better solutions
are available. This section describes a number of issues seen in
many protocols and the common pieces of security technology that may
be useful in addressing them.
4.1. User Authentication
Essentially every system which wants to control access to its
resources needs some way to authenticate users. A nearly uncountable
number of such mechanisms have been designed for this purpose. The
next several sections describe some of these techniques.
4.1.1. Username/Password
The most common access control mechanism is simple USERNAME/PASSWORD
The user provides a username and a reusable password to the host
which he wishes to use. This system is vulnerable to a simple
passive attack where the attacker sniffs the password off the wire
and then initiates a new session, presenting the password. This
threat can be mitigated by hosting the protocol over an encrypted
connection such as TLS or IPSEC. Unprotected (plaintext)
username/password systems are not acceptable in IETF standards.
4.1.2. Challenge Response and One Time Passwords
Systems which desire greater security than USERNAME/PASSWORD often
employ either a ONE TIME PASSWORD [OTP] scheme or a CHALLENGE-
RESPONSE. In a one time password scheme, the user is provided with a
list of passwords, which must be used in sequence, one time each.
(Often these passwords are generated from some secret key so the user
can simply compute the next password in the sequence.) SecureID and
DES Gold are variants of this scheme. In a challenge-response
scheme, the host and the user share some secret (which often is
represented as a password). In order to authenticate the user, the
host presents the user with a (randomly generated) challenge. The
user computes some function based on the challenge and the secret and
provides that to the host, which verifies it. Often this computation
is performed in a handheld device, such as a DES Gold card.
Both types of scheme provide protection against replay attack, but
often still vulnerable to an OFFLINE KEYSEARCH ATTACK (a form of
passive attack): As previously mentioned, often the one-time password
or response is computed from a shared secret. If the attacker knows
the function being used, he can simply try all possible shared
secrets until he finds one that produces the right output. This is
made easier if the shared secret is a password, in which case he can
mount a DICTIONARY ATTACK -- meaning that he tries a list of common
words (or strings) rather than just random strings.
These systems are also often vulnerable to an active attack. Unless
communication security is provided for the entire session, the
attacker can simply wait until authentication has been performed and
hijack the connection.
4.1.3. Shared Keys
CHALLENGE-RESPONSE type systems can be made secure against dictionary
attack by using randomly generated shared keys instead of user-
generated passwords. If the keys are sufficiently large then
keysearch attacks become impractical. This approach works best when
the keys are configured into the end nodes rather than memorized and
typed in by users, since users have trouble remembering sufficiently
long keys.
Like password-based systems, shared key systems suffer from
management problems. Each pair of communicating parties must have
their own agreed-upon key, which leads to there being a lot of keys.
4.1.4. Key Distribution Centers
One approach to solving the large number of keys problem is to use an
online "trusted third party" that mediates between the authenticating
parties. The trusted third party (generally called a a KEY
DISTRIBUTION CENTER (KDC)) shares a symmetric key or password with
each party in the system. It first contacts the KDC which gives it a
TICKET containing a randomly generated symmetric key encrypted under
both peer's keys. Since only the proper peers can decrypt the
symmetric key the ticket can be used to establish 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 have CERTIFICATES [PKIX] which
they then use to authenticate in some protocol-specific way, as in
[TLS] or [S/MIME]. A certificate is a signed credential binding an
entity's identity to its public key. The signer of a certificate is
a CERTIFICATE AUTHORITY (CA), whose certificate may itself be signed
by some superior CA. In order for this system to work, trust in one
or more CAs must be established in an out-of-band fashion. Such CAs
are referred to as TRUSTED ROOTS or ROOT CAS. The primary obstacle
to this approach in client-server type systems is that it requires
clients to have certificates, which can be a deployment problem.
4.1.6. Some Uncommon Systems
There are ways to do a better job than the schemes mentioned above,
but they typically don't add much security unless communications
security (at least message integrity) will be employed to secure the
connection, because otherwise the attacker can merely hijack the
connection after authentication has been performed. A number of
protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap a
user's password into a shared key which can be used as input to a
cryptographic protocol. One major obstacle to the deployment of
these protocols has been that their Intellectual Property status is
extremely unclear. Similarly, the user can authenticate using public
key certificates (e.g., S-HTTP client authentication). Typically
these methods are used as part of a more complete security protocol.
4.1.7. Host Authentication
Host authentication presents a special problem. Quite commonly, the
addresses of services are presented using a DNS hostname, for
instance as a URL [URL]. When requesting such a service, one has to
ensure that the entity that one is talking to not only has a
certificate but that that certificate corresponds to the expected
identity of the server. The important thing to have is a secure
binding between the certificate and the expected hostname.
For instance, it is 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 does not provide end-to-end security
because the hostname-IP mapping is not secure unless secure name
resolution [DNSSEC] is being used. This is a particular problem when
the hostname is presented at the application layer but the
authentication is performed at some lower layer.
4.2. Generic Security Frameworks
Providing security functionality in a protocol can be difficult. In
addition to the problem of choosing authentication and key
establishment mechanisms, one needs to integrate it into a protocol.
One response to this problem (embodied in IPsec and TLS) is to create
a lower-level security protocol and then insist that new protocols be
run over that protocol. Another approach that has recently become
popular is to design generic application layer security frameworks.
The idea is that you design a protocol that allows you to negotiate
various security mechanisms in a pluggable fashion. Application
protocol designers then arrange to carry the security protocol PDUs
in their application protocol. Examples of such frameworks include
GSS-API [GSS] and SASL [SASL].
The generic framework approach has a number of problems. First, it
is highly susceptible to DOWNGRADE ATTACKS. In a downgrade attack,
an active attacker tampers with the negotiation in order to force the
parties to negotiate weaker protection than they otherwise would.
It's possible to include an integrity check after the negotiation and
key establishment have both completed, but the strength of this
integrity check is necessarily limited to the weakest common
algorithm. This problem exists with any negotiation approach, but
generic frameworks exacerbate it by encouraging the application
protocol author to just specify the framework rather than think hard
about the appropriate underlying mechanisms, particularly since the
mechanisms can very widely in the degree of security offered.
Another problem is that it's not always obvious how the various
security features in the framework interact with the application
layer protocol. For instance, SASL can be used merely as an
authentication framework -- in which case the SASL exchange occurs
but the rest of the connection is unprotected, but can also negotiate
traffic protection, such as via GSS, as a mechanism. Knowing under
what circumstances traffic protection is optional and which it is
required requires 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 allows new installations
to provide better authentication while not forcing existing sites
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 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 simply to 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 is by
claiming that his private key has been compromised and that some
attacker (though not necessarily the relying party) signed the
disputed message. In order 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 that the
message was signed.
Additionally, the relying party might attempt to trick the signing
party into signing one message while thinking he's signing another.
This problem is particularly severe when the relying party controls
the infrastructure that the signing party uses for signing, such as
in kiosk situations. In many such 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 tightly bound, it is 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, 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 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
While the distinction between authentication and authorization is
intuitive when using simple authentication mechanisms such as
username and password (i.e., everyone understands the difference
between the administrator account and a user account), with more
complex authentication mechanisms the distinction is sometimes lost.
With certificates, for instance, presenting a valid signature does
not imply authorization. The signature must be backed by a
certificate chain that contains a trusted root, and that root must be
trusted in the given context. For instance, users who possess
certificates issued by the Acme MIS CA may have different web access
privileges than users who possess certificates issued by the Acme
Accounting CA, even though both of these CAs are "trusted" by the
Acme web server.
Mechanisms for enforcing these more complicated properties have not
yet been completely explored. One approach is simply to attach
policies to ACLs describing what sorts of certificates are trusted.
Another approach is to carry that information with the certificate,
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 mechanism for
securing (meaning integrity protecting, authenticating, and possibly
encrypting) all sensitive traffic. One approach is to secure the
protocol itself, as in [DNSSEC], [S/MIME] or [S-HTTP]. Although this
provides security which is most fitted to the protocol, it also
requires considerable effort to get right.
Many protocols can be adequately secured using one of the available
channel security systems. We'll discuss the two most common, 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. The IPsec
protocols support varying granularities of user identification,
including for example "IP Subnet", "IP Address", "Fully Qualified
Domain Name", and individual user ("Mailbox name"). These varying
levels of identification are employed as inputs to access control
facilities that are an intrinsic part of IPsec. However, a given
IPsec implementation might not support all identity types. In
particular, security gateways may not provide user-to-user
authentication or have mechanisms to provide that authentication
information to applications.
When AH or ESP is used, the application programmer might not need to
do anything (if AH or ESP has been enabled system-wide) or might need
to make specific software changes (e.g., adding specific setsockopt()
calls) -- depending on the AH or ESP implementation being used.
Unfortunately, APIs for controlling IPsec implementations are not yet
standardized.
The primary obstacle to using IPsec to secure other protocols is
deployment. The major use of IPsec at present is for VPN
applications, especially for remote network access. Without
extremely tight coordination between security administrators and
application developers, VPN usage is not well suited to providing
security services for individual applications since it is difficult
for such applications to determine what security services have in
fact been provided.
IPsec deployment in host-to-host environments has been slow. Unlike
application security systems such as TLS, adding IPsec to a non-IPsec
system generally involves changing the operating system, either by
modifying with the kernel or installing new drivers. This is a
substantially greater undertaking than simply installing a new
application. However, recent versions of a number of commodity
operating systems include IPsec stacks, so deployment is becoming
easier.
In environments where IPsec is sure to be available, it represents a
viable option for protecting application communications traffic. If
the traffic to be protected is UDP, IPsec and application-specific
object security are the only options. However, designers MUST NOT
assume that IPsec will be available. A security policy for a generic
application layer protocol SHOULD NOT simply state that IPsec must be
used, unless there is some reason to believe that IPsec will be
available in the intended deployment environment. In environments
where IPsec may not be available and the traffic is solely TCP, TLS
is the method of choice, since the application developer can easily
ensure its presence by including a TLS implementation in his package.
In the special-case of IPv6, both AH and ESP are mandatory to
implement. Hence, it is reasonable to assume that AH/ESP are already
available for IPv6-only protocols or IPv6-only deployments. However,
automatic key management (IKE) is not required to implement so
protocol designers SHOULD not assume it will be present. [USEIPSEC]
provides quite a bit of guidance on when IPsec is a good choice.
4.5.2. SSL/TLS
Currently, the most common approach is to use SSL or its successor
TLS. They provide channel security for a TCP connection at the
application level. That is, they run over TCP. SSL implementations
typically provide a Berkeley Sockets-like interface for easy
programming. The primary issue when designing a protocol solution
around TLS is to differentiate between connections protected using
TLS and those which are not.
The two primary approaches used have a separate well-known port for
TLS connections (e.g., the HTTP over TLS port is 443) [HTTPTLS] or to
have a mechanism for negotiating upward from the base protocol to TLS