Designing Network Security
l Port Numbers
l Security Technologies
l Export Controls on Cryptography
l Threats in an Enterprise Network
l Considerations for a Site Security Policy
l Design and Implementation of the Corporate Security Policy
l Incident Handling
l Securing the Corporate Network Infrastructure
l Securing Internet Access
l Securing Dial-In Access
l Sources of Technical Information
Reporting and Prevention Guidelines: Industrial Espionage and Network
Intrusions
l
l Basic Cryptography
l Introduction to IP Multicast
l Multicast Basics
l Internet Group Management Protocol
l Mutlimedia Multicast Applications
l Distance Vector Multicast Routing Protocol
l PIM Dense Mode
l PIM Sparse Mode
l Core-Based Trees
l Multicast Open Shortest Path First
l Using PIM Dense Mode
l Using PIM Sparse Mode
l PIM Rendezvous Points
l Connecting to DVMRP Networks
l Multicast over Campus Networks
l Multicast over NBMA Networks
l Multicast Traffic Engineering
l Inter-Domain Multicast Routing
l Introduction
l Preface
l Appendix A-PIM Packet Formats
The port numbers are divided into three ranges, which are described in Table C-1:
l The well-known ports are those in the range 0 through 1023.
l The registered ports are those in the range 1024 through 49151.
The dynamic or private ports are those in the range 49152 through 65535.
Table C-1: Port Assignments
Keyword Decimal Description
ssh 22/tcp SSH Remote Login Protocol
ssh 22/udp SSH Remote Login Protocol
tacacs 49/tcp Login Host Protocol (TACACS)
tacacs 49/udp Login Host Protocol (TACACS)
domain 53/tcp Domain Name Server
l
Port Numbers
tacacs-ds 65/tcp TACACS-Database Service
tacacs-ds 65/udp TACACS-Database Service
kerberos 88/tcp Kerberos
kerberos 88/udp Kerberos
https 443/tcp HTTP protocol over TLS/SSL
https 443/udp HTTP protocol over TLS/SSL
smtps 465/tcp SMTP protocol over TLS/SSL (was ssmtp)
smtps 465/udp SMTP protocol over TLS/SSL (was ssmtp)
isakmp 500/tcp ISAKMP protocol
isakmp 500/udp ISAKMP protocol
nntps 563/tcp NNTP protocol over TLS/SSL (was snntp)
nntps 563/udp NNTP protocol over TLS/SSL (was snntp)
sshell 614/tcp SSL shell
sshell 614/udp SSL shell
kerberos-adm 749/tcp Kerberos administration
kerberos-adm 749/udp Kerberos administration
kerberos-iv 750/udp Kerberos Version 4
ftps-data 989/tcp FTP protocol, data, over TLS/SSL
ftps-data 989/udp FTP protocol, data, over TLS/SSL
Port Numbers
http://wwwin.cisco.com/cpress/cc/td/cpress/internl/dns/appc.htm (2 of 4) [02/02/2001 17.32.05]
ftps 990/tcp FTP protocol, control, over TLS/SSL
ftps 990/udp FTP protocol, control, over TLS/SSL
telnets 992/tcp Telnet protocol over TLS/SSL
telnets 992/udp Telnet protocol over TLS/SSL
imaps 993/tcp IMAP4 protocol over TLS/SSL
imaps 993/udp IMAP4 protocol over TLS/SSL
ircs 994/tcp IRC protocol over TLS/SSL
ircs 994/udp IRC protocol over TLS/SSL
pop3s 995/tcp POP3 protocol over TLS/SSL (was spop3)
pop3s 995/udp POP3 protocol over TLS/SSL (was spop3)
socks 1080/tcp SOCKS
socks 1080/udp SOCKS
pptp 1723/tcp PPTP
pptp 1723/udp PPTP
radius 1812/tcp RADIUS
radius 1812/udp RADIUS
radius-acct 1813/tcp RADIUS Accounting
radius-acct 1813/udp RADIUS Accounting
http-alt 8080/tcp HTTP Alternate (see port 80)
Port Numbers
Security Technologies
Identity Technologies
Secure Passwords
S/Key Password Protocol
Token Password Authentication Schemes
PPP Authentication Protocols
PPP Password Authentication Protocol
PPP Challenge-Handshake Authentication Protocol
PPP Extensible Authentication Protocol
PPP Authentication Summary
Protocols Using Authentication Mechanisms
The TACACS+ Protocol
The RADIUS Protocol
The Kerberos Protocol
The Distributed Computing Environment
The FORTEZZA
Security in TCP/IP Layers
Application Layer Security Protocols
SHTTP
Transport Layer Security Protocols
The Secure Socket Layer Protocol
The Secure Shell Protocol
The SOCKS Protocol
Network Layer Security
The IP Security Protocol Suite
Using Security in TCP/IP Layers
Virtual Private Dial-Up Security Technologies
The Layer 2 Forwarding Protocol
A Sample Scenario
The Point-to-Point Tunneling Protocol
Security Technologies
http://wwwin.cisco.com/cpress/cc/td/cpress/internl/dns/ch02.htm (1 of 50) [02/02/2001 17.32.23]
Decoupling Traditional NAS Functionality
Protocol Overview
The Layer 2 Tunneling Protocol
Protocol Overview
A Sample Scenario
Using VPDN Technologies
Authentication
Authorization
Addressing
Accounting
Advantages of Using VPDNs
Additional Considerations
Security Technologies
A wide range of security technologies exists that provide solutions for securing network access and data
transport mechanisms within the corporate network infrastructure. Many of the technologies overlap in
solving problems that relate to ensuring user or device identity, data integrity, and data confidentiality.
Note Throughout this book, authentication, authorization, and access control are incorporated into the
concept of identity. Although these concepts are distinct, they all pertain to each individual user of the
network---be it a person or device. Each person or device is a distinct entity that has separate abilities
within the network and is allowed access to resources
based on who they are. Although in the purest sense, identity really pertains only to authentication, in
many cases, it makes sense to discuss the entities' authorization and access control at the same time.
Authentication is the process of validating the claimed identity of an end user or a device (such as clients,
servers, switches, routers, firewalls, and so on). Authorization is the process of granting access rights to a
user, groups of users, or specified system; access control is limiting the flow of information from the
resources of a system to only the authorized persons or systems in the network. In most of the cases we
will study, authorization and access control are subsequent to successful authentication.
This chapter describes security technologies commonly used for establishing identity (authentication,
authorization, and access control) as well as for ensuring some degree of data integrity and
confidentiality in a network. Data integrity ensures that the data has not been altered or destroyed except
by people who are explicitly intended to modify it; data confidentiality ensures that only the entities
allowed to see the data see it in a usable format.
The intent is to develop a basic understanding of how these technologies can be implemented in
corporate networks and to identify their strengths and weaknesses. The following categories have been
selected in an attempt to group the protocols according to shared attributes:
l Identity technologies
l Security in TCP/IP structured layers
l Virtual private dial-up security technologies
l Public Key Infrastructure and distribution models
Note Many of the technologies discussed here either have been, or are in the process of being
standardized by the IETF. For information on more technical details and latest developments, refer to
Appendix A, "Sources of Technical Information." This appendix contains pointers to the IETF working
groups that produce the RFCs and drafts relating to the technologies discussed here.
Identity Technologies
This section describes the primary technologies used to establish identity for a host, an end-user, or both.
Authentication is an extremely critical element because everything is based on who you are. In many
corporate networks, you would not grant authorized access to specific parts of the network before
establishing who is trying to gain access to restricted resources. How foolproof the authentication method
is depends on the technology used.
We can loosely categorize authentication methods as those where there is local control and those where
you provide authentication verification through a trusted third party.
One of the potential weaknesses in some authentication methods is who you trust. Many authentication
methods rely on a third party to verify someone's identity. The strength of this verification is the limiting
factor in the strength of the authentication. When using a third party to authenticate an end user or
device, ask yourself, "What is the likelihood that the third party I'm counting on to provide the
authentication verification has been compromised?"
The technologies discussed in this section include variants of secure passwords, which provide varying
degrees of security and are offered by most vendors today. Many protocols will authorize some form of
connection setup after authentication is successfully verified. In dial-up environments, a peer-to-peer link
level connection is established; sometimes, additional access control mechanisms can be employed at
higher levels of the protocol stack, such as permitting access to hosts with certain IP addresses accessing
specific applications. We will look at different protocols that often use an initial authentication process to
then grant authorization and access control.
Note Digital certificates can be used as an authentication method, as discussed in detail in "Public Key
Infrastructure and Distribution Models," later in this chapter.
Secure Passwords
Although passwords are often used as proof for authenticating a user or device, passwords can easily be
compromised if they are easy to guess, if they are not changed often enough, and if they are transmitted
in cleartext across a network. To make passwords more secure, more robust methods are offered by
encrypting the password or by modifying the encryption so that the encrypted value changes each time.
This is the case with most one-time password schemes; the most common being the S/Key protocol and
the token password authentication schemes.
S/Key Password Protocol
The S/Key One-Time Password System, released by Bellcore and defined in RFC 1760, is
a one-time password generation scheme based on MD4 and MD5. The S/Key protocol is designed to
counter a replay attack when a user is attempting to log in to a system. A replay attack in the context of
login is when someone eavesdrops on a network connection to get the login ID and password of a
legitimate user and later uses it to gain access to the network.
The operation of the S/Key protocol is client/server based: the client is typically a PC, and the server is
some flavor of UNIX. Initially, both the client and the server must be configured with the same pass
phrase and an iteration count. The iteration count specifies how many times a given input will be applied
to the hash function. The client initiates the S/Key exchange by sending an initialization packet; the
server responds with a sequence number and seed, as shown in Figure 2-1.
Figure 2-1: The Initial S/Key Exchange
The client then computes the one-time password, a process that involves three distinct steps: a
preparatory step, a generation step, and an output function (see Figure 2-2).
The client then computes the one-time password, a process that involves three distinct steps: a
preparatory step, a generation step, and an output function (see Figure 2-2).
Figure 2-2: Computing the S/Key One-Time Password
1. In the preparatory step, the client enters a secret pass phrase. This pass phrase is concatenated
with the seed that was transmitted from the server in cleartext.
2. The generation step applies the secure hash function multiple times, producing a 64-bit final
output.
3. The output function takes the 64-bit one-time password and displays it in readable form.
The last phase is for the client to pass the one-time password to the server, where it can be verified (see
Figure 2-3).
Figure 2-3: Verifying the S/Key Password
The server has a file (on the UNIX reference implementation, it is /etc/skeykeys) containing, for each
user, the one-time password from the last successful login. To verify an authentication attempt, the
authentication server passes the received one-time password through the secure hash function once. If the
result of this operation matches the stored previous one-time password, the authentication is successful
and the accepted one-time password is stored for future use.
Because the number of hash function applications executed by the client decreases by one each time, this
ensures a unique sequence of generated passwords. However, at some point, the user must reinitialize the
system to avoid being unable to log in again. The system is reinitialized using the keyinit command,
which allows the changing of the secret pass phrase, the iteration count, and the seed.
When computing the S/Key password on the client side, the client pass phrase can be of any
length---more than eight characters is recommended. The use of the non-secret seed allows a client to use
the same secret pass phrase on multiple machines (using different seeds) and to safely recycle secret pass
phrases by changing the seed.
Note Many implementations require the generated one-time password to be entered either using a
cut-and-paste approach, or manually. In manual entry scenarios, the one-time password is converted to,
and accepted, as a sequence of six short (one- to four-letter) English words. Each word is chosen from a
dictionary of 2,048 words; at 11 bits per word, all one-time passwords may be encoded. Interoperability
requires that all S/Key system hosts and calculators use the same dictionary.
Token Password Authentication Schemes
Token authentication systems generally require the use of a special card (called a smart card or token
card), although some implementations are done using software to alleviate the problem of losing the
smart card or token card. These types of authentication mechanisms are based on one of two alternative
schemes: challenge-response and time-synchronous authentication.
The challenge-response approach is shown in Figure 2-4. The following steps carry out the
authentication exchange:
Step 1 The user dials into an authentication server, which then issues a prompt for a user ID.
Step 2 The user provides the ID to the server, which then issues a challenge---a random number that
appears on the user's screen.
Step 3 The user enters that challenge number into the token or smart card, a
credit-card-like device, which then encrypts the challenge with the user's encryption key and displays a
response.
Step 4 The user types this response and sends it to the authentication server. While the user is obtaining a
response from the token, the authentication server calculates what the appropriate response should be
based on its database of user keys.
Step 5 When the server receives the user's response, it compares that response with the one it has
calculated.
If the two responses match, the user is granted access to the network. If they don't match, access is
denied.
Figure 2-4: Challenge-Response Token Authentication
The time-synchronous authentication scheme is shown in Figure 2-5. In this scheme, a proprietary
algorithm executes in the token and on the server to generate identical numbers that change over time.
The user dials into the authentication server, which issues a prompt for an access code. The user enters a
personal identification number (PIN) on the token card, resulting in digits displayed at that moment on
the token. These digits represent the one-time password and are sent to the server. The server compares
this entry with the sequence it generated; if they match, it grants the user access to the network.
