7.1 What is Network Security?
Let us introduce Alice
and Bob ,
two people who want to communicate "securely." This being a networking
text, we should remark that Alice and Bob may be two routers that want
to securely exchange routing tables, two hosts that want to establish a
secure transport connection, or two email applications that want to exchange
secure e-mail - all case studies that we will consider later in this chapter.
Alice and Bob are well-known fixtures in the security community, perhaps
because their names are more fun than a generic entity named "A" that wants
to securely communicate with a generic entity named "B." Illicit
love affairs, wartime communication, and business transactions are the
commonly cited human needs for secure communications; preferring the first
to the latter two, we're happy to use Alice and Bob as our sender and receiver,
and imagine them in this first scenario.
7.1.1 Secure Communication
We said that Alice and Bob want to communicate "securely," but what precisely
does this mean? Certainly, Alice wants only Bob to be able
to understand a message that she has sent, even though they are communicating
over an "insecure" medium where an intruder (Trudy, the intruder) may intercept,
read, and perform computations on whatever is transmitted from Alice to
Bob. Bob also wants to be sure that the message that he receives
from Alice was indeed sent by Alice, and Alice wants to make sure that
the person with whom she is communicating is indeed Bob. Alice and Bob
also want to make sure that the contents of Alice's message have
not been altered in transit. Given these considerations, we can identify
the following desirable properties of secure communication:
-
Secrecy. Only the sender and intended receiver should be able
to understand the contents of the transmitted message. Because eavesdroppers
may intercept the message, this necessarily requires that the message be
somehow encrypted (disguise data) so that an intercepted message can not
be decrypted (understood) by an interceptor. This aspect of secrecy is
probably the most commonly perceived meaning of the term "secure communication."
Note, however, that this is not only a restricted definition of secure
communication (we list additional aspects of secure communication below),
but a rather restricted definition of secrecy as well. For example,
Alice might also want the mere fact that she is communicating with Bob
(or the timing or frequency of her communications) to be a secret!
We will study cryptographic techniques for encrypting and decrypting data
in section 7.2.
-
Authentication. Both the sender and receiver need to confirm
the identity of other party involved in the communication - to confirm
that the other party is indeed who or what they claim to be. Face-to-face
human communication solves this problem easily by visual recognition.
When communicating entities exchange messages over a medium where they
can not "see" the other party, authentication is not so simple. Why,
for instance, should you believe that a received email containing a text
string saying that the email came from a friend of yours indeed came from
that friend? If someone calls on the phone claiming to be your bank
and asking for your account number, secret PIN, and account balances for
verification purposes, would you give that information out over the phone?
Hopefully not. We will examine authentication techniques in section
7.3, including several that, perhaps surprisingly, also rely on the cryptographic
techniques we study in section 7.2
-
Message Integrity. Even if the sender and receiver are able
to authenticate each other, they also want to insure that the content of
their communication is not altered, either malicously or by accident, in
transmission. Extensions to the checksumming techniques that we encountered
in reliable transport and data link protocols will also be studied in section
7.3; these techniques also rely on cryptographic concepts in section 7.2
Having established what we mean by secure communication, let us next consider
exactly what is meant by an "insecure channel." What information
does an intruder have access to, and what actions can be taken on the transmitted
data? Figure 7.1-1 illustrates the scenario.
Figure 7.1-1: Sender, receiver and intruder (Alice, Bob, and
Trudy)
Alice, the sender, wants to send data to Bob, the receiver. In
order to securely exchange data, while meeting the requirements of secrecy,
authentication, and message integrity, Alice and Bob will exchange both
control message and data messages (in much the same way that TCP senders
and receivers exchange both control segments and data segments).
All, or some of these message will typically be encrypted. A passive
intruder can listen to and record the control and data messages on
the channel; an active intruder can remove messages from the channel
and/or itself add messages into the channel.
7.1.2 Network Security Considerations in the Internet
Before delving into the technical aspects of network security in the following
sections, let's conclude our introduction by relating our fictitious characters
- Alice, Bob, and Trudy - to "real world" scenarios in today's Internet.
Let's begin with Trudy, the network intruder. Can a "real world" network
intruder really listen to and record network messages? Is it easy to do
so? Can an intruder actively inject or remove messages from the network?
The answer to all of these questions is an emphatic "YES." A packet
sniffer is a program running in a network attached device that passively
receives all data-link-layer frames passing by the device's network interface.
In a broadcast environment such as an Ethernet LAN, this means that the
packet sniffer receives all frames being transmitted from or to all hosts
on the local area network. Any host with an Ethernet card can easily
serve as a packet sniffer, as the Ethernet interface card needs only be
set to "promiscuous mode" to receive all passing Ethernet frames.
These frames can then be passed on to application programs that extract
application-level data. For example, in the telnet scenario shown
in Figure 7.1-2, the login password prompt sent from A to B, as well
as the password entered at B are "sniffed" at host C. Packet
sniffing is a double-edged sword - it can be invaluable to a network administrator
for network monitoring and management (see Chapter 8) but also used by
the unethical hacker. Packet-sniffing software is freely available
at various WWW sites, and as commercial products. Professors teaching
a networking course have been known to assign lab exercises that involve
writing a packet-sniffing and application-level-data-reconstruction program.
Figure 7.1-2: packet sniffing
Any Internet-connected device (e.g., a host) necessarily sends IP datagrams
into the network. Recall from Chapter 4 that these datagrams carry
the sender's IP address, as well as application-layer data. A user
with complete control over that device's software (in particular its operating
system) can easily modify the device's protocols to place an arbitrary
IP address into a datagram's source address field. This is known as IP
spoofing. A user can thus craft an IP packet containing
any payload (application-level) data it desires and make it appear as if
that data was sent from an arbitrary IP host. Packet sniffing and IP spoofing
are just two of the more common forms of security "attacks" on the
Internet. These and other network attacks are discussed in the collection
of essays [Denning 1997]. A summary of reported
attacks is maintained at the CERT Coordination Center [CERT
1999].
Having established that there are indeed real bogeymen (a.k.a. "Trudy")
loose in the Internet, what are the Internet equivalents of Alice and Bob,
our two friends who need to communicate securely? Certainly, "Bob"
and "Alice" might be human user at two end systems, e.g., a real
Alice and a real Bob who really do want to exchange secure email.
(e.g., a user wanting to enter a credit card in a WWW form for an electronic
purchase). They might also be participants in an electronic commerce
transaction, e.g., a real Alice might want to securely transfer her credit
card number to a WWW server to purchase an item on-line. Similarly,
a real Alice might want to interact with her back on-line. As noted in
[RFC 1636], however, the parties needing secure
communication might also themselves be part of the network infrastructure.
Recall that the domain name system (DNS, see section 2.5), or routing daemons
that exchange routing tables (see section 4.5) require secure communication
between two parties. The same is true for network management applications,
a topic we examine in the following chapter. An intruder that could
actively interfere with, control, or corrupt DNS lookups and updates, routing
computations, or network management functions could wreak havoc in the
Internet.
Having now established the framework, a few of the most important definitions,
and the need for network security, let us next delve into cryptography,
a topic of central importance to many aspects of network security..
References
[Cert 1999] CERT, "CERT Summaries," http://www.cert.org/summaries/
[Denning 1997] D. Denning
(Editor), P. Denning (Preface), Internet Besieged : Countering Cyberspace
Scofflaws, Addison-Wesley Pub Co, (Reading MA, 1997).
[Kessler 1998] G.C. Kessler, An Overview of Cryptography, May
1998, Hill Associates, http://www.hill.com/TechLibrary/index.htm
[NetscapePK 1998] Introduction to Public-Key Cryptography, Netscape
Communications Corporation, 1998, http://developer.netscape.com/docs/manuals/security/pkin/contents.htm
[GutmannLinks 1999] P. Gutman, Security Resource Link Farm,
http://www.cs.auckland.ac.nz/~pgut001/links.html
[GutmannTutorial 1999] P.Gutmann, Godzilla Crypto Tutorial,
http://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html
[RFC 1636] R. Braden, D. Clark,
S. Crocker, C. Huitema, "Report of IAB Workshop on Security in the Internet
Architecture," RFC 1636,
Nov. 1994.
[RSA 1999] RSA's Cryptography FAQ, http://www.rsa.com/rsalabs/faq/
[Punks 1999] Cypherpunks Web Page, ftp://ftp.csua.berkeley.edu/pub/cypherpunks/Home.html
Copyright 1999-2000 . Keith W. Ross and Jim Kurose. All rights
reserved.