Citation
Enforcing access control policies in internetwork environments

Material Information

Title:
Enforcing access control policies in internetwork environments
Creator:
Park, Hyun, 1960-
Publication Date:
Language:
English
Physical Description:
ix, 138 leaves : ill. ; 29 cm.

Subjects

Subjects / Keywords:
Access control systems ( jstor )
Authentication ( jstor )
Cryptography ( jstor )
Data encryption ( jstor )
Data security ( jstor )
Identifiers ( jstor )
Internet ( jstor )
Key signatures ( jstor )
Local area networks ( jstor )
Network security ( jstor )
Computer and Information Science and Engineering thesis, Ph. D
Computer networks -- Security measures ( lcsh )
Computer networks -- Security measures -- Mathematical models ( lcsh )
Computers -- Access control ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF
Internetworking (Telecommunication) ( lcsh )
Genre:
bibliography ( marcgt )
non-fiction ( marcgt )

Notes

Thesis:
Thesis (Ph. D.)--University of Florida, 1996.
Bibliography:
Includes bibliographical references (leaves 132-137).
General Note:
Typescript.
General Note:
Vita.
Statement of Responsibility:
by Hyun Park.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
The University of Florida George A. Smathers Libraries respect the intellectual property rights of others and do not claim any copyright interest in this item. This item may be protected by copyright but is made available here under a claim of fair use (17 U.S.C. §107) for non-profit research and educational purposes. Users of this work have responsibility for determining copyright status prior to reusing, publishing or reproducing this item for purposes other than what is allowed by fair use or other copyright exemptions. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder. The Smathers Libraries would like to learn more about this item and invite individuals or organizations to contact the RDS coordinator (ufdissertations@uflib.ufl.edu) with any additional information they can provide.
Resource Identifier:
023823814 ( ALEPH )
35828390 ( OCLC )

Downloads

This item has the following downloads:


Full Text












ENFORCING ACCESS CONTROL POLICIES IN INTERNETWORK ENVIRONMENTS












By

HYUN PARK


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY


UNIVERSITY OF FLORIDA


1996






























To God,


my parents, and my wife, Haewon.













ACKNOWLEDGMENTS


First of all, I would like to express my sincere gratitude to my dissertation advisor, Dr. Randy Chow, for his guidance and support, which made the completion of this work possible, and also for his philosophical advice on both my academic and non-academic life, which made me more mature, personally and scholastically. I also want to express my thanks to Dr. Newman-Wolfe for his numerous fruitful discussions which provided deeper insights into some parts of this research. Thanks also go to Dr. Sartaj Sahni, Dr. Jih-Kwon Peir, and Dr. Haniph A. Latchman for their many constructive questions and witty suggestions for my research work. Furthermore, I wish to thank all the faculty members in CISE department who stimulated my interests and equiped me with the methodology to explore the magic world of computer sciences.

Special thanks go to my parents for their continued support, spiritual and financial. They have never lost great confidence in my ability throughout the years at the University of Florida. None of my efforts would have been fruitful without their unparalleled love.

Finally, words are never enough to express my gratitude to my lovely wife, Haewon, for her constant love, patience, and encouragement during difficult times, and for her unreserved devotion to the care of our family.

Praise God for all He has done for me!













TABLE OF CONTENTS


ACKNOWLEDGMENTS ............................. iii

LIST OF FIGURES ................................ vii

ABSTRACT .................................... viii

CHAPTERS

1 INTRODUCTION ............................... 1

1.1 Computer Security ............................ 1
1.1.1 Objectives .. .. .... .... . .. .. ... . .. . .. .. . 1
1.1.2 Security Services ......................... 2
1.2 Internetwork Security ........................... 5
1.2.1 Security Attacks ......................... 5
1.2.2 Internetwork Security Models .................. 7
1.2.3 Access Control in Internetwork ................. 9

2 BACKGROUND AND LITERATURE REVIEW .................. 14

2.1 Preamble ........ ................................. 14
2.2 Internetwork Access Control ............................ 14
2.2.1 Firewall Approach ...... ........................ 16
2.2.2 Distributed Systems Approach ....................... 18
2.2.3 Packet-Level Authentication Approach ................ 20
2.3 Interdomain Authentication ............................. 22
2.3.1 Authentication Protocols .......................... 24
2.3.2 Interdomain Authentication Protocols ................. 27
2.3.3 Formal Protocol Analysis and Evaluation ............... 29
2.4 Secure Control of Transit Internetwork Traffic ................ 29
2.4.1 Issues in Internetwork Environments .................. 30
2.4.2 Policies ........ .............................. 31
2.4.3 Controlling Transit Internetwork Traffic ................ 35

3 PACKET-LEVEL ACCESS SECURITY SCHEME ................ 44

3.1 Motivation ........................................ 44








3.2 Network Environment .............
3.3 Components of PASS ...............
3.3.1 Internet Access Control Gateways .
3.3.2 Pass Key ..................
3.3.3 PASS End-Systems ...........
3.3.4 Certification Authorities ....... 3.4 Protocol Description ..............
3.4.1 Notation ..................
3.4.2 Session Initiation Phase .......
3.4.3 Packet Forwarding Phase .......
3.4.4 Session Revocation ...........
3.5 Review of the Protocol .............
3.5.1 Exception Handling .........
3.5.2 Design Issues in Internet Environme 3.6 Overhead Analysis...............
3.6.1 System Overhead ............
3.6.2 Network Overhead ..........
3.6.3 Comparison with Other Schemes .


4 INTER-DOMAIN AUTHENTICATION WITHOUT AN ARBITER .... 74

4.1 M otivation ................. .... ......... .. . 74
4.2 Public-Key Certificate Infrastructure .................. 76
4.2.1 Certificate Authorities ...... ...................... 76
4.2.2 X-509 Directory Authentication Service ................. 77
4.3 A Secure and Efficient Interdomain Authentication Protocol ..... ..83
4.3.1 Notation ....... .............................. 83
4.3.2 The Protocol ....... ........................... 84
4.3.3 Informal Analysis ...... ......................... 85
4.4 Formal Protocol Analysis Using BAN Logic .... .............. 86
4.5 Preventing Replay Attacks ...... ........................ 90
4.6 Variations of the Protocol ...... ........................ 93
4.6.1 One-Way Authentication .......................... 93
4.6.2 Mutual Authentication with One-Way Pass ... .......... 95

5 SECURE CONTROL OF TRANSIT INTERNETWORK TRAFFIC . .. 97

5.1 Motivation ....... ................................. 97
5.2 Security Issues in Transit Control ......................... 98
5.2.1 Security Threats ....... ......................... 98
5.2.2 Cryptographic Tools ...... ....................... 99
5.3 Description of Security Mechanisms ....................... 102
5.3.1 Secure Distribution of Policy Terms ................... 103
5.3.2 Route Setup Phase ...... ........................ 105
5.3.3 Packet Forwarding Phase ......................... 108


nt








5.4 Cost of Security Mechanisms ............................ 111
5.4.1 Per Packet Signature Overhead ..................... 112
5.4.2 Packet Length Overhead .......................... 114
5.4.3 Setup Overhead ................................ 114
5.4.4 Other Per Packet Processing Costs .................. 115

6 CONCLUSIONS AND FUTURE WORK ....................... 116

6.1 Internetwork Access Control ............................ 116
6.2 Interdomain Authentication ............................ 117
6.3 Secure Control of Transit Internetwork Traffic ................ 118

APPENDICES

A INTEGRATION OF PASS WITH GTGB ....................... 120

A.1 GTGB Functionality ...... ........................... 120
A.2 Configuration of Gemini-UF GTGB Testbed ................. 123
A.2.1 Private-To-Private Secure Connections ................ 124
A.2.2 Private-To-Public Connections ...................... 125
A.3 Integration of PASS into GTGB Testbed .................... 126
A.3.1 Coexistence of PASS and GTGB ..................... 126
A.3.2 Interactions between PASS and GTGB ................ 128

B ACRONYMS ........ .................................. 131


REFERENCES ........ ................................... 132

BIOGRAPHICAL SKETCH .................................. 138














LIST OF FIGURES


1.1 Four categories of security attacks ..... ................... 6
1.2 A model for internetwork security ..... ................... 8
1.3 Model for internetwork access security .... ................. 10

3.1 A simplified state diagram for a source IACG ................ 50
3.2 An illustration of two communicating PASS ADs .............. 55
3.3 IP Version 4 PASS data packet format .... ................. 63
3.4 An example of PASS scheme ...... ...................... 65
3.5 IP Version 6 authentication header containing pass ............. 68

4.1 X.509 CA hierarchy: A hypothetical example ................ 81
4.2 An interdomain authentication protocol ..... ................ 84
4.3 A scenario of a replay attack ...... ...................... 91

A.1 The network configuration of Gemini-UF Testbed .............. 124















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the Requirements for Doctor of Philosophy ENFORCING ACCESS CONTROL POLICIES IN INTERNETWORK ENVIRONMENTS By


Hyun Park


August 1996


Chairman: Dr. Randy Chow
Major Department: Computer and Information Science and Engineering


Internetwork environments are inherently vulnerable to security threats due to their openness, the nonexistence of a centralized management authority, and insecure communication channels. Moreover, increasing internetwork applications frequently require connecting administrative domains with competing interests. In this environment, unauthorized access to network resources is an issue of growing concern. However, existing resource access control schemes either have security flaws or suffer from inconvenience and inflexibility.

The primary objective of this research is to develop a secure and efficient internetwork access control scheme. Packet-level access security scheme (PASS) is a








policy enforcement mechanism for stub domains. In using PASS, a unique pass-key is assigned to each communication session after both end-systems are authorized and authenticated. Any valid packet should include a proper pass in it to be verified by access control gateways. The security and performance of this protocol has been assessed and the results are compared with those of other schemes.

PASS uses a new interdomain authentication protocol that utilizes ITU-T X.509 directory authentication service as the public key provider. This removes an unrealistic assumption about the availability of a trusted third party used in most other existing protocols. The authentication goals of the protocol are verified by using BAN logic. Two variations of this protocol are given for the situations that require one-way authentication and one-way pass.

To complement the policy enforcing scheme, a secure transit control mechanism is proposed. Controlling access to network resources in intermediate domains is closely related to packet routing. Therefore, two policy-based routing protocols are investigated first and security mechanisms are provided to the Inter-Domain Policy Routing protocol (IDPR). The cost of the added security is analyzed for several modes of transit packet verification.

In summary, this dissertation is devoted to the investigation of three main issues in internetwork access control. First, a secure and efficient stub domain access control scheme is proposed. Next, a new interdomain authentication protocol is presented to be used in PASS. Finally, a secure transit control scheme is proposed by adding security mechanisms to IDPR.














CHAPTER 1
INTRODUCTION


1.1 Computer Security

Computer security is assuring the confidentiality, integrity, and availability of components of computing systems. The three principal pieces of a computing system subject to attacks are hardware, software, and data. These three pieces, and the communications between them, constitute the basis of computer security vulnerabilities. In order to realize the computer security, a secure computer system needs to provide security services to its users.

1.1.1 Objectives

The principal objectives of computer security can be more specifically characterized as the protection of confidentiality, integrity, and availability of computing system components, as discussed below.

* Protecting data confidentiality means preventing unauthorized accessing

of computing system assetts. The type of access is read-type access such as

reading, viewing, printing, or even just knowing the existence of an object.


* Protecting data integrity means preventing unauthorized modification of

computing system assetts. In this context, modification includes writing, changing, changing status, deleting, and creating.








* Protecting data availability means preventing denial of service. An authorized user should not be prevented from accessing those objects to which he or

she or it has a legitimate access right.

1.1.2 Security Services

To achieve these computer security objectives, a secure computer system needs to provide a set of computer security services, with which the users can protect their data and the system can protect its resources appropriately, as follows.


" Authentication is verifying the identity of a user or a process on behalf of

him. In simple words, an authentication service tries to answer the question,

who are you ?


" Authorization is controlling all accesses of users to data, according to some

pre-determined security policies. In simple words, an authorization service tries

to answer the question, what can you access and how ?


" Auditing is recording occurrences of all security-relevant events in an audit

log. In simple words, an auditing service tries to answer the question, what

have you done ?


Authentication

The authentication service is usually the first service that a user will experience before he can proceed to perform other computing tasks. Since all other security services depend on authentication, an authentication service must be reliable and robust. Password is the most common approach to authenticate the identity of a








user. Password is a secret character string kept by both a user and the authentication service. Password security has been extensively researched and many guidelines of selecting good passwords that are hard to guess have been proposed [1, 2]. The secrecy and integrity of the system password file which stores the passwords of all the users must be fully protected. Some modern computer systems use smart cards [3] to authenticate users. A smart card is a device held by a user and embedded with a microprocessor, memory, and algorithms to compute an identification string with the user's password as its input. The advantages of smart cards are that the authentication process is more secure than simply using user passwords and a user can login to a computer system from anywhere if there is a smart card reader (since the encryption algorithm and mechanism are provided by the smart card, rather than by the machine). More advanced authentication methods use biometric authentication devices [4] to recognize a user's personal characteristics like his/her voice, retina, or fingerprints. Showing the greatest promise of authentication, biometric advices need advanced speech or image processing technology. Their high costs are only justified where the benefits they provide are absolutely required. Authorization

Each access of a user, or a process executing on behalf of him, to some data storage needs to be controlled by the authorization service. To describe how data access should be mediated, explicit and well-defined security policies or access control policies need to be defined. An access control policy consists of a set of rules used by the system to determine whether an access attempt by a user to a specific data








storage should be granted or denied. A security model or access control model is a formal representation (by mathematical notations and formalisms) of the security policies enforced by the system. It offers a means to depict how each data access is regulated by the authorization service. Note that a security policy is defined to reflect the security requirements of an organization or its users, and should be established independent of any security models. A security model describes how each access decision is determined, in order not to violate the security policy. Naturally, it is desirable to choose a security model that can enforce a wide variety of security policies.

A security model only provides an abstract concept of enforcement of security policies. In practice, it needs to be realized by a security mechanism or access control mechanism that consists of hardware and software features, operating functions, and management procedures to perform the activities of an authorization service. One security model may be implemented by several distinct types of security mechanisms, with each having its advantages and disadvantages from different viewpoints of management. Regardless of how powerful a security model is, operation efficiency of a security mechanism and ease of its management framework are crucial to the applicability of a security model.

Auditing

The auditing service can be thought as the last defense line of a secure computer system, because once other security services fail and a security violation occurs, the auditing log can be reviewed and examined to trace the responsible users and reveal




5


the imperfection of security mechanisms. The latter often provides the most valuable information for improving the security services of a computer system. The capability of selecting the audit events to be recorded is necessary to minimize the expense of auditing and to allow efficient analysis. For obvious reasons, the audit data itself must be protected from unauthorized modification and destruction.

1.2 Internetwork Security

The requirements of information security within an organization have undergone a major change in the last several decades with the introduction of distributed systems and the use of networks and communication facilities for carrying data between terminal user and computer and between computers. Network security measures are needed to protect data during their transmission. In fact, the term network security is somewhat misleading, because virtually all business, government, and academic organizations interconnect their data processing equipment with a collection of interconnected networks. Such a collection is often referred to as an internetworl, and internetwork security will be a more suitable term in this case.

1.2.1 Security Attacks

The types of attacks on the security of a computer system or network are best characterized by viewing the function of the computer system as providing information. In general, there is a flow of information from a source, such as a file or a region of main memory, to a destination, such as another file or a user. This normal flow is

'Not to be confused with the term (DARPA) Internet, which refers to a specific collection of networks that has become something of a global public networking utility. The Internet may be one of the facilities used by an organization to construct its internetwork.










Source Destination
(a) Normal Flow


0- 0

(b) Interruption (c) Interception





(d) Modification (e) Fabrication

Figure 1.1. Four categories of security attacks depicted in Figure 1.1(a). The remaining parts of the figure show the following four general categories of attack:


" Interruption is when an asset of the system is destroyed or becomes unavailable or unusable. This is an attack on availability. Examples include destruction of a piece of hardware, such as a hard disk; the cutting of a communication

line; or the disabling of the file management system.


" Interception is when an unauthorized party gains access to an asset. This

is an attack on confidentiality. The unauthorized party could be a person, a program, or a computer. Examples include wiretapping to capture data in a

network, and the illicit copying of files or programs.


" Modification is when an unauthorized party not only gains access to but tampers with an asset. This is an attack on integrity. Examples include changing








values in a data file, altering a program so that it performs differently, and

modifying the content of messages being transmitted in a network.


9 Fabrication is when an unauthorized party inserts counterfeit objects into the

system. This is an attack on authenticity. Examples include the insertion of

spurious messages in a network or the addition of records to a file.


A useful categorization of these attacks is in terms of passive attacks and active attacks. Examples of passive attacks are eavesdropping or monitoring of transmissions. The goal of the opponent is to obtain information that is being transmitted. Two types of attacks are involved here: release of message contents and traffic analysis. Active attacks involve some modification of the data stream or creation of a false stream and can be subdivided into four categories: masquerade, replay, modification of messages, and denial of service. The security services discussed in the previous section encounter these security attacks and make use of one or more security mechanisms to provide the services.

1.2.2 Internetwork Security Models

A general model for internetwork security is shown in Figure 1.2. Messages are transferred from one party to another across an internetwork. The two parties, who are the principals 2 in this transaction, must cooperate for the information exchange to take place. A logical information channel is established by defining a

2The entities in a networked or distributed system that can be distinctly identified are collectively referred to as principals.

















MessageMessage
Information channel Message
Secret informt
information information Secuity-ela~edISecurity-related tasoaontranstormation


Opponent


Figure 1.2. A model for internetwork security

route through the internetwork from source to destination and by the cooperative use of communication protocols (e.g., TCP/IP) by the two principals.

Security aspects come into play when it is necessary or desirable to protect the information transmission from an opponent who may present a threat to confidentiality, authenticity, and so on. All the techniques for providing security have two components:


* A security-related transformation on the information to be sent. Examples

include the encryption of the message, which scrambles it so that it is unreadable by the opponent, and the addition of a code based on the contents of the

message, which can be used to verify the identity of the sender.


e Some secret information shared by the two principals and, hopefully, unknown

to the opponent. An example is an encryption key used in conjunction with the








transformation to scramble the message before transmission and unscramble it

on reception.


A trusted third party may be needed to achieve secure transmission. For example, a third party may be responsible for distributing the secret information to the two principals while keeping it from any opponent. A third party may be needed to arbitrate disputes between the two principals concerning the authenticity of a message transmission.

This general model shows us that there are four basic tasks in designing a particular security service:


1. Design an algorithm for performing the security-related transformation. The

algorithm should be such that an opponent cannot defeat its purpose.


2. Generate the secret information to be used with the algorithm.


3. Develop methods for the distribution and sharing of the secret information.


4. Specify a protocol to be used by the two principals that makes use of the security

algorithm and the secret information to achieve a particular security service.


1.2.3 Access Control in Internetwork

There are other security-related situations of interest that do not neatly fit in this model but that are important in internetwork environment. A general model of these situations is illustrated by Figure 1.3, which reflects a concern for protecting an information system from unwanted access.








Information System

Computing
[ Resources
.Access channel eper





Figure 1.3. Model for internetwork access security

Traditional internetworks often ignore the issue of interdomain access control, either because they connect organizations within a large administrative unit such as university or government, or because they connect research institutions with little need to limit information flow. With increasing internetwork applications, emerging internetworks are frequently required to connect administrative domains, or ADs3, that may have competing interests. In this environment, unauthorized access to network resources is an issue of growing concern since security threats and the damage associated with such unauthorized accesses, can be very high. Therefore, ADs should be able to interconnect without exposing their internal resources to unrestricted external access. Moreover, internetwork components should be able to control incoming and outgoing traffic by specifying or constraining the ADs to, and through which, the traffic can flow. Therefore, it is necessary to implement an access control mechanism to protect these resources. To do this, all of the access control requirements should be specified clearly.

3An AD is defined as a collection of network resources under control of a single administrative entity [5]








Access control requirements

Due to the characteristics of the internetwork discussed above, some security measures are required to protect resources from unauthorized accesses. However, in an internetwork, the goal is not simply to prohibit access by outsiders; some outside access is explicitly desired. The goal is to support access to certain machines, services, and processes, while preventing access to all other internal facilities. Therefore, it is not desirable that externally accessible facilities be physically isolated from all strictly internal resources for this would interfere with internal access to local information and resources. Similarly, requiring that all internal facilities adopt additional security measures to cope with external connections may interfere with internal communication and resource sharing. This measure also requires global knowledge of all interconnections. Therefore, it is desirable to implement logical networks that can be isolated from one another yet share physical resources.

To achieve this goal more effectively, only the administrators of the external links, gateways, and the internal resources that are made explicitly accessible should be required to take security action in response to an external connection. Owners of all other internal resources should be assured that their facilities are not accessible to outsiders. Therefore, each organization must control all exit and entry points to its internal network assuming no direct external connections are permitted without going through one of these control points. This minimizes interference with the organization's internal facilities and operations. However, this approach does impose new requirements on the functionality of gateways and the communication protocols








used. In other words, this nondiscretionary control mechanisms in the gateway should have access to logical information about packets, such as organizational affiliation of source and destination.

Finally, the costs imposed by a control scheme should be minimized. That is, per-packet processing and storage overhead in border router and end-system, additional communication during connection setup, and packet length overhead should be minimized. Other costs such as router crash should also be minimized. Classification of access controls

An internetwork is composed of a number of Administrative Domains, or ADs as discussed in previous sections. It is important to distinguish between two dominant types of ADs: stub and transit. Stub ADs are interested mainly in communication with other stub ADs, that is, providing communication for their constituent endsystems. A campus network is an example of a stub AD. Transit ADs are involved in providing transit service for traffic between stub ADs. NSFNET is an example of a transit AD. Finally, there are also hybrid ADs that combine transit service with end-point communication.

Considering these types of ADs, an internetwork access control scheme can be devided into two parts: stub network access control and transit network access control. Stub network access control is concerned with policy enforcement with respect to non-transit internetwork traffic. In other words, the issue is how an AD can control both inbound (addressed to a local end-system) and outbound (sourced by a local end-system) traffic at its network boundaries. On the other hand, transit network




13


access control is concerned with policy enforcement with respect to transit internetwork traffic. Controlling access to transit network resources (such as routers and links) requires additional protocol support because of the need to coordinate routing decisions among all intervening networks. These two access controls should work in harmony to achieve a dependable policy enforcement in an internetwork environment.














CHAPTER 2
BACKGROUND AND LITERATURE REVIEW


2.1 Preamble

The research work in this dissertation falls into three main areas of computer and communications security: internetwork access control, interdomain authentication, and secure control of internetwork transit traffic. In each of these research areas, the problems found, the methods used, and the results achieved will be discussed in detail in a separate chapter. A thorough overview of previous research in these fields is given in this chapter.

2.2 Internetwork Access Control

There have been many works on internet security. Kent and Voydock suggested some security mechanisms in high-level network protocols in their early works [6, 7]. Branstad et al. [8] and Nelson [9] have presented the development of a security architecture for secure data network system (SDNS) project within the International Standardization Organization's (ISO) Open Systems Interconnection (OSI) computer network reference model. They have developed a Security Protocol (SP4) at the ISO transport layer to provide either connectionless or connection-oriented security services. The importance of placing different security services at various layers of the OSI architecture are discussed by Ramaswamy and Fumy [10, 11]. Since Bellovin








[12] pointed out some security breaches in DOD's TCP/IP protocol suite, many suggestions [13, 14, 15, 16] have been made to address internet security problems. Most of these works are on providing confidentiality and integrity of information in transit by either inserting a security sublayer or modifying existing protocol layers to utilize existing cryptographic tools.

With increasing internetwork application, emerging internetworks are frequently required to connect ADs that may have competing interests. Therefore, ADs are required to control accesses to the local resources by enforcing policies at their borderline. There have been a stream of research works that focus on the resource access control in internetworked or distributed systems:


* The firewall approach isolates an AD's internal networks from the outside world

with special machines called firewalls. Conceptually, there are two types of

firewalls: network level and application level.

" The distributed systems approach provides an access control as a part of a

more comprehensive security service for a certain distributed system. This often requires substantial software modification to take advantage of it since the security service is normally well integrated within the fundamental distributed

services.

" The packet-level authentication approach enforces access control policy on packet

level. That is, border routers examine traffic flows so that only the packets with proper authenticator are allowed to exit from a local domain and to enter into

a destination domain.








2.2.1 Firewall Approach

A firewall is a system or a group of systems that enforces an access control policy between two networks. The actual means whereby this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one to block traffic, and the other to permit traffic. Some firewalls place a greater emphasis on blocking traffic, while others emphasize permitting traffic. Firewalls can be classified into two main categories: network level firewall and application level firewall.

Network level firewalls generally make their decisions based on the source, destination addresses and ports in individual IP packets as in screend [17, 18] and in TAMU [19]. In general, no context is kept; decisions are made based only on the contents of the current packet. The administrator maintains a list of the acceptable machines and services and a stoplist of unacceptable machines or services. However, this approach works only if the lists are static or if the source and destination ID's carry sufficient information for access decisions. In other words, if there is a welldefined set of resources that are to be accessible by a well-defined set of entities, then the access control list could be managed manually. Alternatively, if internet addresses are structured in such a way that the gateway can classify a node according to the range into which its internet address falls, the gateway could maintain an access control list by node classes (internet address regions), and thereby achieve greater flexibility.

I am interested in the more general case of a dynamic environment where network addresses by themselves do not provide sufficient information for the gateway to make








a policy decision about whether or not to permit access; the DARPA Internet is one such environment. Internet addresses are assigned to carry topological, not logical, information [20], while policy decisions are generally based on the latter. Moreover, if the gateway relies solely on the addresses to control the access, the gateway must trust all internal nodes not to masquerade as other nodes, that is, not to fake their internet addresses. In reality, it is not hard to modify one's internet address in a decentralized environment with many personal computers and workstations. The packet level firewall cannot detect this address spoofing attack.

Application level firewalls generally are hosts running proxy servers 1, which permit no traffic directly between networks [21, 22]. A proxy server is an application that mediates traffic between a protected network and the Internet. Proxies are often used instead of router-based traffic controls, to prevent traffic from passing directly between networks. Proxies must "understand" the application protocol being used and the protocol specific security should be configured (e.g., an FTP proxy might be configurable to permit incoming FTP and block outgoing FTP).

Proxy servers are application specific. In order to support a new protocol via a proxy, a proxy must be developed for it. Moreover, having an application in the way in some cases may impact performance and may make the firewall less transparent. Early application level firewalls such as those built using the TIS firewall toolkit, are not particularly transparent to end users and may require some training. One popular set of proxy servers is the TIS Internet Firewall Toolkit (FWTK) which

'It is sometimes referred to as an application forwarder or a application gateway








includes proxies for telnet, rlogin, FTP, X-window, HTTP/Web, and NNTP/Usenet news. SOCKS [23] is a generic proxy system that can be compiled into a client-side application to make it work through a firewall.

While suitable for some situations, high-level gateways suffer from performance overhead of the gateway's high-level processing, and reduced generality and flexibility, since special high-level gateway software must be constructed for each high-level protocol supported. Thus, it would be desirable to implement access control in internet gateways without incurring the costs inherent to high-level gateways.

2.2.2 Distributed Systems Approach

The Open Software Foundation's (OSF's) Distributed Computing Environment (DCE) [24] is a comprehensive, integrated set of services that supports the development, use and maintenance of distributed applications. DCE Security Service includes several components: a DCE authentication service, privilege service, registry service, authenticated RPC, and DCE access control lists. DCE authentication service was built upon the Kerberos V5 source code from MIT's Project Athena. Privilege service allows users to be identified by individual user privilege and by group membership. The user registry ensures the use of unique user names and passwords across the distributed network of systems and services, ensures the accuracy and consistency of this information at all sites, and provides security for updates and changes. It maintains a single, logical database of user account information including user and group naming information, login account information, and general system








properties and policies. It is well integrated with Kerberos to provide an integrated, secure, reliable user account management system.

The DCE security service component is well integrated within the fundamental distributed service2 and data-sharing components3 of DCE. Therefore, DCE security service alone cannot be used in internetwork environment to enforce any access control policy since it was not designed to be used as as a stand-alone security service. In other words, DCE security service is a part of a distributed computing environment architecture that goes beyond simple communication facility and provides a wide range of computer services to applications regardless of the location of the user, the application, or the required resources.

On the other hand, in many internets, such as DARPA Internet, hosts are not coupled as tightly as in distributed systems. They are just interconnected hosts in many different ADs. These host are not often interested in anything beyond using some internetwork applications such as FTP, e-mail, telnet, or WWW service with security. Therefore, it is not reasonable to require these hosts to change their system environment to DCE in order to use DCE security service. A less elaborate and immediate measure will be desirable to provide access control service in this environment. It would be great if an efficient access control scheme can be implemented by just modifying a protocol layer, preferably in lower layers.

As mentioned earlier, DCE authentication service is based on Kerberos V5. That is, an inter-cell authentication (inter-realm authentication in Kerberos term)

2This includes remote procedure call, directory service, time service, security service, and threads service
3This includes distributed file system and diskless support








is performed by a pairwise security sharing [25] or by a realm hierarchy [26]. This will give difficulties for hosts in DCE environment to authenticate principals in nonDCE ADs. Instead, it is not allowed to get service from those servers outside of the distributed system. It would be desirable to be able to accomplish interdomain authentications without much change in system and network environment for many ADs.

Finally, DCE Security Service is based on the Client-Server paradigm. However, this is not always the case with internetworks. An effective access control scheme should work well with both client-server and peer-to-peer communications.

The Secure European System for Applications in a Multi-vendor Environment (SESAME) [27] by European Computer Manufacturer's Association (ECMA) is an approach similar to DCE Security Service except for some implementation details. SESAME implementation also includes Kerberos V5 features and components as a core of the authentication service. Authentication Service extension provides support for authentication based on public key technology. SESAME shares the same characteristics as a security measure for distributed systems as DCE Security Service and is not considered appropriate to be used as an access control scheme in internetwork environments.

2.2.3 Packet-Level Authentication Approach

The VISA scheme [28, 29] implements controls in a packet-forwarding- gateway by working in concert with an access control server (ACS). The ACS carries out the high-level evaluation of communication requests and the gateway enforces the ACS's








decision using the VISA scheme. That is, a gateway only allows a packet with a valid exit visa stamp to exit from and a packet with a valid entry visa stamp to enter into its network. A visa stamp is a mathematical value calculated from packet authentication keys called visa. However, this scheme requires the distribution of visas in plain text for each external session. This requires extra security measures to transport the visas to hosts requesting external sessions safely. Hence, the security of the mechanism depends largely on the protection of the visas during distribution. Moreover, VISA scheme does not specify any authentication protocol for the session initiation stage. The lack of an interdomain authentication mechanism makes this scheme less attractive in an internetwork environment with heterogeneous authentication protocols.

Another packet-level access control scheme proposed by Iqbal et al. [30] formulated an approach for authenticating individual packets from a host for the duration of an external session without distributing packet authentication keys. In this scheme, a chain of pairwise authentications between neighboring principals on the path from the source to the destination host should be accomplished during the session initiation procedure. This pairwise authentication is based on the RSA public key cryptosystem to verify each other's identification. For a specific session, each pair shares a distinct mathematical value called a reference number to be used to extract a packet authentication key from the RSA private key which is shared by the pair. After the session initiation, each valid packet should contain a packet authentication








code (PAC) which is computed from the packet authentication key using DES algorithm. This requires peer communicating entities, including network access control gateways (NACGs) in different organizations, to share their RSA private/public key pairs. This increases vulnerability tremendously since the compromise of any one gateway can make other gateways in other organizations subject to attack when they share RSA private keys. This is not desirable in today's competing and hostile internet environment. Moreover, for all but the nearby hosts, the overhead due to the consecutive pairwise authentications becomes large.

2.3 Interdomain Authentication

In an internetwork environment any two principals on different machines need to authenticate each other before starting communication so that a network intruder cannot impersonate a principal to the other. There are three types of authentication in this environment:


* message content authentication, verifying that the content of a received message

is the same as when it was sent;


* message origin authentication, verifying that the sender of a received message

is the same one recorded in the sender field of a message; and


* general identity authentication, verifying that a principal's identity is as claimed.


Message content authentication is commonly handled by tagging a key-dependent message authentication code (MAC) onto a message before it is sent. Message integrity can be confirmed upon reception by recomputing the MAC and comparing it








with the one attached. Message origin authentication is a subcase of general identity authentication. A successful general identity authentication usually results in a belief held by the authenticating principal (the verifier) that the authenticated principal (the claimant) possesses the claimed identity. Hence, subsequent claimant actions are attributable to the claimed identity.

Authentication is achieved usually based upon cryptography and by using the authentication server that is trusted by all principals in one administrative domain. The authentication server shares a unique master key with each principal, and all the authentication information are conveyed between the server and a principal by encrypting them with the master key of the principal. To authenticate its identity, a principal must demonstrate the ability of recognizing the authentication information encrypted with his own master key, but without revealing it, to the other principal.

Furthermore, distributed applications frequently require that the messages transmitted over the network be confidential only to the communicating peers, which implies at least a session key needs to be distributed first between two communicating principals before a session of confidential data transmission between them can initiate. This session key is also used to provide message origin authentication during data communication following an authentication process. That is, any message encrypted with the session key after authentication is assumed to originate from the peer principal who holds the session key. The distribution of a session key is often carried out concurrently with the authentication process.








2.3.1 Authentication Protocols

Protocols using private key encryption

In 1978 Needham and Schroeder proposed the use of encryption for authentication in computer networks [311. The proposed protocols use private key encryption as well as public key encryption. Since the principals are identified by a secret key, an authentication server is used which stores the names of the principals and the keys belonging to them. This work is the starting point for many authentication protocols that have since been developed.

Denning and Sacco [32] pointed out a flaw in the private key authentication protocol proposed by Needham and Schroeder. They proposed to use timestamps to overcome the vulnerability of replay attack. But this approach has the drawback that it requires an accurate distributed clock and synchronization which is difficult to achieve.

In 1987 Needham and Schroeder again published a protocol that avoids the security deficits shown by Denning and Sacco by using nonces [33]. Their proposal requires an extra interaction between the two communicating principals but doesn't depend on synchronized clocks.

Otway and Rees [341 described a protocol for efficient mutual authentication that also eliminates the weakness discovered by Denning and Sacco. Their protocol is a development of the trusted third party authentication protocols of Needham and Schroeder [31]. It requires a total of only four messages to be exchanged between the three parties involved.








Kerberos [25, 26] is an authentication service that was built for MIT's Project Athena. Kerberos is based on the Needham and Schroeder third party authentication model [31] and uses timestamps to prevent re-use of tickets or replay. It requires a physically secure authentication server. Kerberos uses the Data Encryption Standard (DES) and is therefore not exportable. Some limitations of Kerberos version 4 [25] are pointed out by Bellovin and Merritt [35]. Kerberos version 5 [26] addressed most of these problems.

Kehne et al. [36] developed a nonce-based protocol that offers the same features as Kerberos without the need of synchronized clocks. They show that their protocol uses a minimum number of messages to establish an authentication session key. Protocols using public key encryption

ITU-T Recommendation X.509 [37] proposed an authentication protocol based on public key encryption that uses a one-way handshake. The protocol needs an authentication server which stores public key certificates for those who want to verify the identity of a communication partner. Since the certificates cannot be forged the requirements for the authentication server are not as strong as those for authentication using private key encryption.

Another approach, proposed by Woo and Lam [38], makes use of nonces in the authentication protocol. This protocol has a vulnerability to replay attack and they published a revised version [39] and showed the design steps of flawless security protocol.








SPX [40] is an implementation of an open distributed authentication service architecture based on ISO Standard 9594-8/ITU-T X.509 Directory Public Key Certificates. Its use is intended for open network environments. It doesn't require on-line trusted components. SPX is an initial subset implementation of a larger security architecture called as Digital's Distributed Systems Security Architecture (DSSA). Assuring freshness of messages

In general, all the authentication protocols for distributed systems can be divided into two categories depending upon how the freshness of key-distribution messages is determined. One category of protocols uses nonces. They exchange challenge/response messages to verify whether the response to a key distribution request is fresh or not. Since replay attacks can be effectively prevented by the use of nonces without clock synchronization, most proposed protocols in the literature are noncebased [31, 33, 34, 36, 41, 42].

The other category of protocols uses timestamps to ensure the freshness of messages. These protocols must assume that all machines are properly clock-synchronized. The number of messages required by timestamp-based protocols can be reduced since no round-trip traffic is required to guarantee message freshness as in the case of nonce-based protocols. However, due to the imperfection of clock synchronization [43], timestamp-based protocols are vulnerable to both conventional copy-and-replay and suppress-and-play attacks elaborated by Gong [44].








2.3.2 Interdomain Authentication Protocols

General identity authentication is required between a local host and the local authentication server to verify that a principal's identity is as claimed. Similar authentication is needed between a pair of principals in different administrative domains to initiate a session between them. The intradomain authentication is relatively simple and can be accomplished easily using any authentication protocol available locally such as Kerberos [26]. However, the interdomain authentication requires additional mechanisms since it is not always reasonable to assume the existence of a single trusted authentication server between any two ADs in the internet environment.

As a part of Project Athena at MIT, Kerberos [25, 26, 45] is one of the most promising implementations of the authentication service. It is based on the NeedhamSchroeder protocol and uses timestamps suggested by Denning and Sacco [32] to prevent replays and to reduce messages complexity. Because of its simplicity and reliability, Kerberos has now become the most popular authentication service and adopted by a number of vendors in designing distributed systems.

Kerberos is designed on a client-server model, thus it provides authentication service between a client and a server when the former tries to request a service from the latter. In fact, Kerberos places the authentication service on two kinds of servers: Kerberos server and ticket granting server (TGS). While the Kerberos server authenticates the user when he logins and issues a ticket for a TGS, it is the TGS that issues tickets for individual servers to a client. The limitations and weaknesses of the Kerberos system have been explored by Bellovin and Merritt [35], and most of








them are due to the use of timestamps. While the initial version of Kerberos is based upon a secret-key cryptosystem, the public-key cryptosystem has been incorporated into the version 5.

Kerberos provides a mechanism for supporting inter-realm authentication. The scheme requires that the Kerberos server in one realm trust the Kerberos server in the other realm to authenticate its users. Kerberos V4 [25] uses a pairwise secret sharing to perform inter-realm authentication, which has a scalability problem. That is, if there are N realms, then there must be N(N- 1)/2 secure key exchanges so that each Kerberos realm can interoperate with all other Kerberos realms. Kerberos V5 uses authentication forwarding and realm hierarchy to solve this problem in inter-realm authentication.

Another approach suggested a hierarchical authentication [46]. That is, it suggested higher-level authentication servers that act as authentication servers for the lower-level authentication servers in different domains. The layers of authentication servers can be extended further to cover larger number of domains. However, it is not reasonable to assume that there exists always such a higher-level authentication server that can be trusted by all competing and sometimes hostile ADs. Another well-known authentication service based upon the public-key cryptosystem is SPX [40] developed by DEC. It suggested an interdomain authentication protocol and proposed a design of a proprietary certification system to provide public keys to the principals.








2.3.3 Formal Protocol Analysis and Evaluation

Most authentication protocols found in the literature are described only by listing the messages sent between principals and by explaining what results will be achieved after each step of message transmission, in quite an informal and imprecise way. To formalize the definition of a protocol, Burrows, Abadi, and Needham defined a logic of authentication [42, 47] (hereafter called BAN Logic) to describe the initial assumptions upon which a protocol is based and the meaning of each message in a logical and precise way, and to express exactly what final beliefs can be obtained by communicating principals after the completion of a protocol run. They demonstrated the strength of BAN Logic by applying the logic to a number of authentication protocols and evaluating the nature of the guarantees those protocols offer. In their well-known paper introducing BAN Logic, the formalized goals of authentication were explicitly stated, and the protocols which cannot achieve these goals were appropriately criticized and improved wherever possible.

2.4 Secure Control of Transit Internetwork Traffic

Network access control methods that restrict the information flow between endsystems on stub domains have been discussed in previous sections. However, controlling access to transit network resources (such as routers and links) require additional protocol support because of the need to coordinate routing decisions among all intervening networks. Organizations cannot simply enforce policy restrictions on a unilateral basis at packet forwarding time. Internetwork routing decisions must be








made according to policy-related parameters such as access rights and cost, in addition to the traditional parameters of connectivity and delay [48, 49]. Consequently, policies pertaining to network resources must either be implicit in the topology of an internetwork, or advertised to the anticipated resource users. Only then can entities throughout the internetwork determine the logical, policy-based connectivity of an internetwork and compute valid routes.

2.4.1 Issues in Internetwork Environments

This section defines some of terminology and assumptions regarding internetwork environments in order to provide appropriate background for the subsequent discussion.

Internetwork topology

Some routing protocols such as Exterior Gateway Protocols (EGP) [50] place restrictions on internet scale and topology. However, any inter-AD routing protocol should have the potential of supporting very large scale internetworking. In an internet of enormous size such as DARPA Internet it would be unwise to design a protocol that relied on topological restrictions; enforcement would be almost impossible. Consequently, one of the design goals should be allowing maximum degree of flexibility in regard to the configuration of the internetwork.

A traditional network hierarchy includes long haul, regional and campus (stub) networks. However, there are exceptions to the hierarchy in the form of lateral (bypass) links. These exceptions to the otherwise regular topology are not dispensable and must be supported, perhaps at the expense of optimality.








Protection of network resources

Many discussions of network security are actually discussions of end-system protection in a network environment [6, 51, 52, 53]. One of our assumptions in the design of transit network controls is that both stub and transit ADs have valuable network resources that are themselves the subject of policy [54]. From this perspective, it is imperative to address the protection of network resource in addition to end-system protection.

If control is left to the end-systems, valuable stub-AD network resources may be consumed by unauthorized traffic. Rejecting packets at the end-system is too late from the perspective of network resource usage. Moreover, unrestricted network access increases the vulnerability of ADs to denial of service attacks in the form of packet storms. Finally, some ADs might need to control which routes are used to and from their internal end-systems due to cost or security reasons. Because routing is a network level function, these controls must also involve network level entities and can not be left to transport session end-points [54].

2.4.2 Policies

We can find an analogy between ADs and sovereign countries, each with a specific set of foreign policy statements regarding interaction with foreign entities (other ADs). For example, a country may have policies restricting foreign visitors to specific areas or restricting travel privileges of the local populace when visiting foreign countries. Countries may also have specific policies pertaining to transit travelers, such as restricting entry on the basis of the traveler's itinerary. Security








policies regarding international travel can express policy as to passport and visa requirements, length of stay, etc. Accounting or billing policies may concern, for example, visa fees or departure taxes.

ADs can express similar policies regarding communication with external entities, such as restricting internal systems available for external access or restricting external systems available for internal access. Transit traffic may or may not be allowed, or it may be restricted to specific source and/or destination ADs or end-systems. Policies can also embody security requirements, such as authentication and authorization for inter-AD traffic, as well as accounting and billing conditions [55].

Network level policies are primarily concerned with unauthorized access to network resources, denial of service, and inappropriate accrual of communication-related charges. These threats can all come about through attacks on the authenticity and the integrity of internetwork packet traffic. Some concerns are of greater importance to stub networks and others, to transit networks. Stub and transit policies

Due largely to the nature of service provided, stub and transit ADs tend to express different policies. Policies expressed by stub ADs, for the most part, serve to protect internal resources from external access, while those expressed by transit ADs tend to be cost-related. Another way of making this distinction is to observe that transit ADs, by virtue of providing transit service, are inherently more open than their stub counterparts. Furthermore, subversion of transit AD's policies will, in the worst case, result in denial of service, whereas subversion of stub network polices can








potentially disrupt the end-systems themselves. Another reason for separating the respective policies is the difference in accounting and billing requirements. Stub ADs are more likely to bundle communication costs into billing for end services, if any such billing occurs. Transit ADs are more likely to charge for the communication itself. Finally, stub AD policies include route selection criteria, which dictate how the AD's packets travel to their destinations.

In some respects, the requirements for transit policy enforcement are simpler than those for stub policy enforcement. However, several factors complicate the implementation of the latter. First, in an internetwork, a packet may travel through a number of transit ADs on its way to the destination. Consequently, applicable policies from all transit ADs must be considered when a packet is being sent; whereas for control of stub resources, only the policies of the two end-point ADs need to be taken into account. In addition, transit control has to be reconciled with topology changes (routers or links going down). If in the middle of a connection any component of the route becomes disabled, an entirely different policy may come into effect. Also, when a transit AD decides to account and/or bill for resource usage, coordination is required to pass charges back to the end points. Moreover, stub route selection criteria must be integrated with transit control policies to determine the appropriate routes. These factors add to the complexity of potential enforcement mechanisms.

Based in part on the difference in policies, and in part on the functionality required in any routing (i.e., transit) mechanism, transit and stub AD mechanisms also differ. By analogy with international travel, in most countries transit travelers are








set apart from other visitors. They are issued special transit visas and are restricted in movement and length of stay. I discuss transit mechanisms further in later sections. Policy attributes

Network usage policies can be based upon a number of attributes:


* Endpoint policies place restrictions on the source and/or destination of traffic.


o Path policies place restrictions on other ADs of the path in addition to the

source and destination ADs.


o Security attributes express requirements for authentication, data integrity,

replay detection and privacy.


o Temporal parameters include restrictions on usage based on time of day, day

of the week or other time-related parameters.


o Quality of Service policies discriminate according to the service parameters

(e.g., delay, throughput) made available to different users.


o Accounting/Billing policies express conditions related to charging and accounting.


A typical policy statement can be based upon several policy attributes. For example, the policy statement, "transit voice traffic from AD. is accepted between 2 and 6 a.m. with a per packet charge", applies to transit traffic and combines application protocol, temporal and accounting/billing attributes. Further examples of policy types can be found in RFC1125 [55].








2.4.3 Controlling Transit Internetwork Traffic

There are two basic approaches to controlling transit traffic. In the first part of this section, an approach based on the extension of stub network access control mechanisms is discussed and its limitations are identified. Subsequently, the alternative approaches based on integrating controls into internetwork routing are considered. Extending stub network access controls

One potential method of enforcing transit policy enforcement is to extend existing stub network access control mechanisms to the generalized internetwork model.

Visa protocols [29] were developed originally to provide datagram-level control at AD boundaries. The process of establishing authorization in Visa-controlled transit ADs is essentially the same as for stub ADs in the Visa protocol. The major difference is that the source host must obtain a transit visa for each transit AD that requires one, in addition to obtaining a pair of exit/entry visas from AD.,, and ADd.t. In the worst case, each transit AD's ACS will conduct an authorization and authentication procedure before issuing a transit visa, and each packet will have to carry a separate visa for each intervening AD. Of course, transit ADs may choose to issue visas automatically, or not require any visas at all where transit traffic is concerned. Furthermore, ADs could program their ACSs to obtain and issue transit visa-keys in advance of the actual communication. This would reduce the setup delay at connection establishment time. On the other hand, such mechanisms increase the problems associated with visas expiring before, or while they are in use.








Although the extension of the Visa concept to transit control is rather straightforward, the approach does not scale well to an internetwork where many ADs, both stub and transit, want to control traffic flows. For example, visa acquisition and route setup must be repeated (or adapted) each time an involved visa-router goes down. Moreover, a source AD has no way of determining if it will be issued a visa without incurring the overhead of contacting the particular ACS in question.

The essence of the problem is that transit control is related to packet routing. Therefore, controls for transit should be incorporated into the route calculation itself, not only into the packet forwarding function.

The access control policy in SP3 [56] is also endpoint-oriented. It is concerned mainly with determining whether or not two peers may communicate and what type of information they may exchange. This and other network access control schemes such as router packet filters [17] face the same limitation when it comes to controlling transit traffic. That is, these schemes enforce controls on packet forwarding and do not provide information to the route computation.

In summary. Visa protocols and other network access control mechanisms are best suited for stub network control. Transit network control for large internetworks is more efficiently achieved by integrating policy considerations into the route computation process.

Policy routing

As described earlier, the central goal of transit traffic control is to allow ADs to express and enforce policies regarding transit traffic. Our discussion in the previous








section demonstrates that transit control is intimately related to Inter-AD Routing. An interdomain routing that incorporates policy constraints is called policy routing

(PR).

In this section two approaches of policy routing are summarized. The first is the Border Gateway Protocol (BGP) [57, 58, 59] which is intended to support a limited notion of policy. The second is the Inter-Domain Policy Routing (IDPR) proposal designed to support more general policies [48, 49].

Policy routing operates at the network layer. In both example architectures, only border routers and associated interdomain route servers are directly affected by the presence of the interdomain routing protocols. End-systems and interior routers can continue employing whatever internetworking protocols are desired within their particular ADs. Border routers operate on behalf of the end-systems. For this reason, the term source hereafter refers to the border router in the AD of the source endsystem.

Border Gateway Protocol. BGP is an external gateway protocol for communication between routers in different ADs. BGP is a replacement for the older EGP [50] that was used on the ARPANET. BGP was first proposed in 1989 [49] and Version 3 [58] and Version 4 [57] have been developed so far. Its foremost goal is to provide efficient and robust inter-AD routing with rapid convergence and loop detection for arbitrary internetwork topologies. In addition, it provides policy-based distribution of routing information. It is aimed mainly at transit ADs and can interoperate with other routing protocols.








BGP is designed under the following assumptions:


1. Policies can he expressed using information about the full AD path that packets

will travel to a destination.


2. Transit policies apply uniformly to all endpoints.


BGP uses hop-by-hop routing and a distance vector algorithm for the next hop selection. One common benefit of traditional distance vector algorithms is the ability to hide network structure. Neighboring nodes exchange reachability information for a specific destination in the form of distance metrics corresponding to each next hop. Nodes do not exchange information about subsequent hops to the destination. BGP augments this traditional approach by distributing full AD-level paths. In other words, for each destination advertised, nodes specify the AD-level path to that destination. As a result, BGP provides less information hiding in return for the ability to detect routing loops quickly. By using the full AD path to detect loops BGP avoids imposing topological restrictions on AD interconnection (such as those imposed by EGP). In addition, AD path information can be used as a policy criterion for route selection.

BGP allows for limited policy-based route selection. Each AD's BGP router can select its next hop based on the information provided in the full AD path, in addition to the distance metric. For example, ADA can reject all routes through ADB. On the other hand, each AD must apply the same route selection decision to all packet sources, including itself. For example, ADA cannot reject all routes through ADB for itself without affecting its neighbors, and vice versa. Similarly, an AD can not apply








one policy to one neighbor and a second policy to another neighbor. Since BGP was not intended to implement policies that discriminate between traffic end-points with arbitrary granularity, the approach achieves its goals [60].

Each BGP router can be configured according to its AD's local policy. Even though local policy is not distributed among ADs, it is represented in a universal policy language. A policy in this language is an expression:



[Network - list, AD - path] = preference



The semantics of a policy are as follows: if a routing update for a network in the Network-list is received via the AD-path and its preference metric is higher than that of a path currently in use, then, this update must be redistributed to all ADs.



Inter-Domain Policy Routing. An alternative architecture for policy routing has been developed to support a wider range of policies; the Inter-Domain Policy Routing (IDPR) proposal allows stub and transit ADs to express and exchange packet routing and forwarding policies. The most distinguishing feature of this approach is the use of AD-level source routing. It uses a Link State algorithm 4 to compute source Policy Routes (PRs) at the granularity of ADs. Each AD expresses its policies in a standard form, called Policy Terms (PTs) [49], and distributes them to other ADs. Each AD

4In a link-state protocol a router does not exchange distances with its neighbors. Instead each router actively tests the status of its link to each of its neighbors, sends this information to its other neighbors, which then propagate it throughout the AD. Each router takes this link-state information and builds a complete routing table. Practically, link-state protocol will always converge faster than a distance-vector protocol.








designates special Route Servers (RSs) to collect PTs and compute policy routes for constituent users. The basic assumptions of this model are:


1. Most policies can be classified and expressed in a standard notation.


2. Policies and inter-AD connectivity change relatively slowly.


3. End-point specific policies should be supported.


Two primary concepts in this proposal are Policy Routes (PRs) and Policy Terms (PTs). A PR is a series of ADs. It is essentially an AD-level source route. In other words, there may be multiple physical realizations of a PR given multiple physical connections between ADs and multiple intra-AD routes. The actual selection of a particular physical path is done at packer forwarding time by each intervening AD rather than by the source AD at route computation or route selection time. This lazy evaluation provides for a more adaptive protocol and unrestricted AD interconnection. Policy Terms (PTs) are the units of routing information exchanged by communicating ADs. Each PT represents a distinct policy of the AD that expressed it.

Policies are expressed by source, destination, and transit ADs. The source AD may select all transit ADs while transit and destination ADs control which source and destination ADs can communicate via which directly connected ADs. ADs run link state routing algorithms to compute their respective tables of PRs. There may be multiple PRs listed for the same destination AD, each with a different set of conditions associated with its use (e.g., quality of service, time-of-day, or user class).








Note that ADs (with the exception of the source AD) do not exert control over the entire Policy Route. Referring back to our travel analogy, it is difficult to enforce policies that are based on information that is not verifiable at the point of reference. For example, it is difficult to enforce a policy that dictates non-admittance to anyone who has ever passed through country X, since it is very much dependent on X stamping passports reliably. In the environment of interconnected ADs, a transit AD can verify the previous and next hops because of its direct connections and the feasibility of employing pairwise authentication with the relatively small number of neighbors. Verifying other transit components of the PR is difficult, if not impossible.

Each AD has one or more Route Server (RS), an entity that collects Policy Routing information from other ADs, distributes local policy information to other ADs and computes, as well as issues, PRs to local end-systems. Actual policy enforcement is done at a Policy Gateway (PG) which, in addition to the usual task of forwarding packets, handles validation and verification of the PRs attached to the incoming packets.

A path is established with the first packet carrying the full PR, that is, the complete sequence of ADs in the route and applicable PT identifiers. PGs along the way make sure that the PR agrees with the local PTs (through use of templates, for example). The result is cached so that a specified PR handle can be used in the future to refer to the cached entry. Successive packets carry a PR handle, not a full PR. Many transport level sessions, and even host-pairs, may share a single PR if the policies enabling it are not end-system-specific; this reduces the average








latency and router state overhead associated with interdomain communication. PGs use these handles in the packets to check for cache entries. PGs also may relate return flow packets with forward flow. Given information about the next AD for a particular packet, each PG selects the next PG based on the information exchanged in a traditional routing protocol.

Comparison of approches

Policy routing allows ADs to interconnect to the global internet while still protecting network resources from general, unconstrained use. However, policy routing mechanisms do not preclude the need for network access controls in the border routers of ADs that wish to control access to individual end-systems.

One essential difference between Visa and the policy routing approach is the per session setup overhead. Transit Visa requires that a dialog transpire between the source and each transit-Visa network's ACS, and that corresponding key be distributed. Consequently, the initial setup delay grows in proportion to the number of transit networks. For short transactions such overhead is not acceptable. A PR-based approach such as that in BGP or IDPR avoids this setup dialog through background distribution of policy term information that is used in route computation. The work that the Policy Routing protocols do to distribute policy terms and compute authorized routes must be done at the time of the session setup in Visa. In particular, with Visa protocol this translates into a reject packet, ACS dialog, and visa-key grant message for each AD in the path. Moreover, this assumes that the source attempts communication over a path for which it has authorization. If there is a




43


conflict with even one transit AD's policy, the process must begin again. Policy Routing incorporates policy into the route computation process in advance of the actual communication, thereby avoids this problem.

On the other hand, the PR schemes, as described thus far, rely on post-facto detection of abuse and in that sense, are less secure than network access controls schemes such as Visa protocols. In chapter 5, I address the integration of preventative mechanisms into policy routing to achieve secure control of transit traffic.














CHAPTER 3
PACKET-LEVEL ACCESS SECURITY SCHEME


3.1 Motivation

With increasing internetwork applications, emerging internetworks are frequently required to connect administrative domains (ADs) that may have competing interests. In this environment, security threats of unauthorized accesses to the resources are very high. Therefore, an efficient and effective access control scheme is needed.

However, most work on internetwork security aims to provide confidentiality and integrity of information in transit by either inserting a security sublayer or modifying existing protocol layers to utilize existing cryptographic tools [7, 8, 14, 16]. Although firewalls protect internal resources from unauthorized accesses from outside, this can only be achieved at the expense of inflexibility and inconveniences for the internal users. On the other hand, Security Services of OSF's DCE [24] and ECMA's SESAME [27] are rather complex and exclusive solutions for client/server-based distributed systems and not for immediate use in the internetwork environment. More specifically targeted work towards internetworks [28, 30] are suffer from security vulnerability and excessive overhead.

This led us to develop a more efficient and effective stub-domain mechanism, a packet-level access security scheme (PASS) [61]. PASS requires each organization








to control all the exit and the entry points of its internal network to implement a nondiscretionary access control mechanism to isolate pure-internal resources from externally accessible resources. PASS does not require each AD to have dedicated local access control servers. This makes PASS scheme more acceptable in many situations. Moreover, PASS is efficient in the sense that the protocol overhead is low enough so as not to affect the configuration of existing higher-layer protocols and applications.

The primary goal of PASS is to allow an AD to control communication between its constituent end-systems and end-systems in other ADs to a specific system level. This goal can be achieved if the end-systems involved can be trusted. This trust can only be verified and maintained by strictly controlling the exit and entry of the packets to an AD since the only information available about a packet is attached to the packet in a datagram network. In other words, a packet can only leave the source AD if


" the source end-system has been authorized to communicate with the corresponding destination end-system,


* the packet is originated at the source end-system within a reasonable time

interval,


" the packet is properly addressed for the destination end-system, and


9 the packet has not been modified in transit.








Similarly, a packet can only enter the destination AD if the conditions similar to those mentioned above are met.

3.2 Network Environment

I assume that the internetwork closely follows the model of the DARPA Internet, which is substantially similar to the Open Systems Interconnection (OSI) model. The essential features of the environment are as follows:


* End-systems are autonomous and cannot necessarily be trusted.


* ADs are interconnected with routers; between any pair of end-systems in different ADs there are at least two routers, one belonging to each of the ADs.

The terms border router and interdomain router are equivalent.


* All information flows via datagram packets. A packet consists of a header that

includes addressing and other control information, and a data segment that is

not intelligible to routers.


* A packet may flow through several untrusted ADs on its way to the destination.


* Both source and destination end-system addresses can be forged. It is not

possible (using hardware methods) to determine reliably which end-system actually sent a packet or to prevent a packet from being seen by an unauthorized

end-system.


o Packets traveling across an internetwork may be lost, duplicated, or re-ordered.








* Successive packets between a given end-system pair may travel along different

routes.


In addition to these, there must exist a global name service which, in a secure and reliable fashion, provides a mapping from end-system network addresses to AD identifiers in addition to the rather traditional mapping between end-system names and addresses. ITU-T X.509 [37] will provide this service along with the public key certificates of principals involved.

3.3 Components of PASS

To achieve the goal of this scheme, several components of PASS should work together in concert on a given internetwork environment. The following components of PASS are described in this section: internet access control gateway, passes, endsystems, and certification authority (CA). 3.3.1 Internet Access Control Gateways

An internet access control gateway (IACG) is a border router that uses the PASS protocol to enforce access controls. All interdomain connections must be implemented via PASS-routers. Unlike other border routers, IACG is also responsible for authorization and authentication with end-systems in its local AD. IACGs are trusted and assumed to defend against attempted abuse from external entities. This assumption is critical since these gateways issue and maintain packet authentication keys.








The choice of the authorization and authentication procedures used by an IACG is the decision of each individual AD. The procedure may involve establishing a highlevel conversation with the end-system, in which a password, biographical data, or other authenticating information is requested. The public key based authentication protocol which is used in interdomain authentication can also be used in this intradomain case. Access control decisions may be most appropriately made according to group or class affiliation and associated category sets that determine access rights. The PASS scheme itself does not dictate or constrain any particular authorization scheme. Regardless of the approaches used, the PASS scheme assumes only that a yes/no decision is passed to the PASS software. This dissertation describes the PASS interface to IACG, not the IACG design itself. Finally, significant application-specific access control is left to the end-systems and applications; our scheme addresses only control of access to the hosts on a network.

The functions of an IACG can be summarized as follows:


" On receipt of an AUTH-REQUEST packet from a local end system, an IACG

authorizes and authenticates the host.


* Performs interdomain authentication with a peer IACG during the pass request

procedure on behalf of an end-system in its local AD.


" Issues a new pass to the peer gateway.


* Forwards a new pass which is granted by the peer gateway to the initiating

local host.








e Expires a pass upon termination request by participant host or gateway, or

upon timeout, and notifies all parties involved - hosts and other gateways.


* Traps all packets and searches for a pass in pass list with source, destination

addresses and pass identifier.


* Computes pass with the pass-key found and compares it with the one attached

to the packet.


* Rejects a packet without a valid pass.


* Forwards packets bearing a valid pass through.


* Accepts a PASS-GRANT packet from the remote IACG and adds a new pass

entry to the pass list.


* Issues a REVOKE packet and deletes a pass entry from the pass list.


e Upon pass expiration, it informs the peer IACG of the fact.

Figure 3.1 shows a simplified state diagram for an IACG at a session initiating domain.

3.3.2 Pass Key

A pass key is an unique value assigned to a communication session between a pair of end-systems on different ADs. Depending on the signature method, it may be an encryption key (with DES) or a secret prefix/suffix (with MD5 [621). It is used to compute a packet signature, called here as a pass, for the traffic from a source to a destination end-system. Each packet that belongs to an authorized session carries














DEiSTINATION
OK TOSURC OK










Figure 3.1. A simplified state diagram for a source IACG

a distinct pass value in the IP header option field1 [63] that is a function of pass key and the packet contents.

In most types of communication, packets will flow in both directions, so both end-systems are both a source and a destination at the same time. Therefore, there are two possibilities of key assignment: one-way pass-key and two-way pass-key. A distinct pass-key can be assigned to each direction of communication after two separate one-way authentications. To reduce the protocol overhead, an AD can allow its IACG to issue a two-way pass key automatically after a mutual authentication. With current implementation, each direction of a session is assigned a unique pass key after a successful mutual authentication. This increases the level of security since each destination IACG issues a pass-key for the inbound traffic after successful

'Or in the Authentication Header with IPv6








authorization of the source party. This scheme can be easily modified to assign a twoway pass key to a session for simplicity. This requires an additional authorization for the other direction of traffic.

Each host that makes use of the internetwork communication maintains an active pass list. Each entry in the pass list consists of a pass, pass identifier to differentiate multiple sessions between the same host pair, and the addresses of the machines involved in the session, and any restrictions that may apply such as pass lifetime. IACGs also maintain a pass list to enforce access control on the traffic flowing through them.

3.3.3 PASS End-Systems

End-systems using PASS protocol to communicate each other are called PASS end-systems. Any PASS end-system who wants to communicate with end-systems outside of its AD must obtain a pass-key allowing its packets to exit from the local AD and enter to the destination AD. In order to obtain exit authorization it needs to contact one of the local IACGs which authenticates its identity and authorizes its access rights. The local IACG then contacts the peer IACG in the destination AD to request a pass-key for its local end-system. After successful authorization and authentication, the remote IACG grants a pass-key to the local IACG, which in turn forwards it to the source end-system.

Thereafter, a pass (computed with the corresponding pass-key) must be attached to every packet sent from the requesting end-system to the apparent destination. To








do this, an end-system should have a proper means for generating pass and a secure storage for active pass list.

An end-system does not have to have knowledge of the local IACG's address; this may instead be supplied by the IACG when an end-system first attempt to communicate across the AD boundary without a proper pass. An end-system can use an authentication scheme available locally or can be authenticated by an IACG during session initiation phase of the PASS protocol.

3.3.4 Certification Authorities

In the X.509 directory-authentication framework, a certification authority (CA) is an authority trusted by one or more users to create and provide public-key certificates for them. The heart of the X.509 scheme, which is used during interdomain authentication, is the public-key certificate associated with each user. These user certificates are assumed to be created by some trusted certification authority (CA) and placed in the directory by the CA or by the user. The directory server itself is not responsible for the creation of public keys or for the certification function; it merely provides an easily accessible location for users to obtain certificates. The public-key certificate includes the following elements:


* Version: differentiates among successive versions of the certificate format; the

default is 1988.


* Serial number. an integer value, unique within the issuing CA, which is unambiguously associated with this certificate.








" Algorithm identifier the algorithm used to sign the certificate, together with

any associated parameters.


" Issuer. the CA that created and signed this certificate.


* Period of validity consisting of two dates: the first and last on which the

certificate valid.


" Subject: the user to whom this certificate refers.


" Public-key information: the public key of the subject, plus an identifier of the

algorithm for which this key is to be used.


* Signature: covers all of the other fields of the certificate, and consists of a hash

code of the other fields, encrypted with the CA's private key.


The CA signs the certificate with its secret key. If the corresponding public key is known to a user, then that user can verify that a certificate signed by the CA is valid. User certificates generated by a CA have the following characteristics:


" Any user with access to the public key of the CA can recover the user public

key that was certified


" No party other than the certification authority can modify the certificate without this being detected


If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates can be placed in the directory for access by all users. In addition,








a user can transmit his or her certificate directly to other users. In either case, once a principal A is in possession of the other principal B's certificate, B has confidence that messages it encrypts with A's public key will be secure from eavesdropping and that messages signed with A's private key are unforgeable.

If there is a large community of users, it may not be practical for all users to subscribe to the same CA because it is the CA that signs certificates, each participating user must have a copy of the CA's own public key in order to verify signatures. This public key must be provided to each user in an absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical for there to be a number of CAs, each of which securely provides its public key to some fraction of the users. An example of CA hierarchy is described in detail later.

3.4 Protocol Description

PASS protocol consists of three phases. In the session initiation phase, an endsystem first obtains authorization for transferring packets to a destination end-system outside of its own AD. If successful, the local IACG requests pass-key to the IACG in the destination AD and acquires it. In the packet forwarding phase, the pass key is used to generate a packet data signature that is attached to all packets belonging to the authorized session. Finally, the session revocation involves the termination of a pass either because of normal expiration or by explicit revocation. In the remainder of this section, each protocol phase is discussed in detail.



















Figure 3.2. An illustration of two communicating PASS ADs


In this protocol, I assume a one-way communication, that is, an one-way transfer of packets from a source end-system to a destination end-system. Therefore, only one-way authentication is sufficient to do this. A different pass-key should be assigned to the other direction of a communication through the same steps of the protocol. However, this protocol can be extended for two-way communications by just using a mutual authentication and a two-way pass-key. Figure 3.2 illustrates two participating ADs which communicate using PASS protocol, where H is the source end-system and Hb is the corresponding destination.

3.4.1 Notation

The following notation is used throughout the description of the protocol:


" PassKij denotes a pass-key shared by a source end-system Hi and a destination

end-system Hi.


" KUi, KR, denote public and private keys of principal i.


" EK[Data], DK[Data] denote encryption and decryption, respectively, of Data

with key K.








* EKR, [Data], DKU, [Data] denote signing and verification, respectively, of Data

using a public key system.


* Fhah(Data) is a hash value of one-way hash function applied to Data.

3.4.2 Session Initiation Phase

Each interdomain communication between PASS end-systems requires a session initiation procedure which does the following:

* Authorization and authentication of two communicating end-systems by each

of their local IACGs.

e Issuance of a pass-key as a result of successful authorization and authentication.


o Distribution of the pass-key to all parties involved. Exit authorization

The protocol is put in motion when an end-system, Ha, in ADa begins communication with another end-system, Hb, in ADb. H, may already know that its intended destination is in a different AD, either because it has previously communicated with Hb or it may have discovered this through some external mechanism (e.g., a name server). In this case, Ha may communicate directly with an IACG in its AD, IACGa, by sending an AUTH-REQUEST packet. Otherwise, since the packet carries no pass, the exit IACG will reply with a REJECT packet which notifies Ha that the intended destination is non-local, and that it must acquire a pass by first getting authorization and authentication from a local IACG. Therefore, these first two packets can be saved if Ha knows that its intended destination, Hb, is in a different AD beforehand.












DATA Ha 4 IACGa : [Ha, Hb, Data (3.1) REJECT IACGa - Ha: [Ha, fb, IACGa] (3.2)



Ha then sends an authorization/authentication request packet, referred here as AUTH-REQUEST packet, to IACGa.





AUTH-REQUEST Ha --+ IACGa: [Ha,EKRH.[Hb, TSH.]] (3.3)



This message is intended to establish the identity of Ha and the authenticity and the integrity of the message. This is done by signing the packet with the private key of Ha. If conventional encryption is used, the signing would be done with the secret key shared by Ha and IACGa. AUTH-REQUEST packet also claims that the message was intended for Hb. On the other hand, the timestamp, TSH. guarantees the freshness of the message.

IACGa now needs Ha's public key to extract the contents of the signed packet. It is often the case that IACGa has the public key of H in its local storage for faster processing. Otherwise, IACGa should obtain the public key certificate which contains the public key of H from X.509 directory.

With the successful extraction of packet contents, IACG checks TSH.. Otherwise (i.e., the packet has been modified during transmission), IACGa either discards








the packet or sends a REJECT packet to H. notifying it of the fact. IACGa does similar things when TSH. does not look normal to prevent replay attacks [64].

Next, IACG, has to authorize communication between H, and Hb. This step is dependent on the particular policy employed by AD,. For example, it may involve a higher-level authentication dialog between IACG. and Ha. The details of this procedure are beyond the scope of this paper. If the authorization fails, IACGa notifies Ha that it is not allowed to communicate with Hb. Otherwise, IACGa proceeds to finish up the authentication either by following the local authentication protocol available or by verifying the AUTH-REQUEST packet using the public key of H,.

Upon successful authentication, IACGa sends PASS-REQUEST packet to the destination AD, ADb. This request should be delivered to the counterpart IACG, IACGb. IACG, may know the address of IACGb from the previous communication in which case PASS-REQUEST may be sent directly. It could also obtain IACGb's address via a name service query [65]. Otherwise, PASS-REQUEST packet is addressed to the destination end-system, Hb, and eventually it is picked up by IACGb since it does not have proper pass on it.





PASS-REQUEST IACG,, -- Hb: [IACGa, EKR1ACGa[Ha, Hb, TSa]] (3.4)



Again, this packet is signed with IACGa's private key to provide proof of authenticity and integrity of the message. Timestamp TS. guarantees the timeliness and should be unique since it is used as a pass identifier later.








Entry authorization

When a PASS-REQUEST reaches ADb, it is trapped by IACGb since it does not have proper pass on it. IACGb first verifies that Hb indicated in the PASS-REQUEST is in fact an end-system in its AD. This is necessary in order to minimize time spent on potentially malformed PASS-REQUESTs. Next, IACGb authorizes communication between H. and Hb. When it fails, the REJECT packet will be sent to IACGa. Otherwise it proceeds to the authentication procedure. In order to authenticate its contents by recomputing the signature, IACGb needs the public key of IACG. This public key is found in the public key certificate of IACG which is obtained from the X.509 directory as a response to the request of IACGb. In the mean time, IACG, requests the public key certificate of IACGb to a local X.509 Certification Authority

(CA), CAa, to get the public key of IACGb. Both IACGs may look up local storage to find the other IACG's public key used in previous communications.

Using the public key of IAC Ga, KUIACG,, IACGb recomputes the signature of the PASS-REQUEST and verify both its origin and data integrity. Both freshness and uniqueness of the PASS-REQUEST packet are inferred from the enclosed timestamp, TSa [43, 66].

Pass grant and distribution

After successful authentication, IACGb issues a new pass key in the following form:












PASS-GRANT: IACGb - IACGa:

EKRIACGb[Ha, Hb, Alg, LT, EKUIACGa[EKRIACGb[TSa, PassKab]] (3.5)



A PASS-GRANT packet includes the source and destination end-system addresses, Ha and Hb, respectively, that are authorized to use this pass. In other words, this states that the pass key has been issued by Hb and is being used for the packets destined for Hb from Ha. PASS routers IACGa and IACGb use these endsystem addresses to locate the appropriate pass-key when they associate incoming packets with a particular communication session.

The timestamp TSa is used here as an identifier of the pass key which is assigned to a pair of end-systems, Ha and Hb. This value should be unique and unused before. In that sense, it is used here as a nonce [67].

LT is the lifetime of a pass-key to be used to expire the pass-key when the given condition is met. A pass-key can be made obsolete at a specific system time or after some specific amount of time elapsed. A maximum number of packets transmitted or a maximum amount of data transferred can also be used as a LT.

PassKab is a pass-key granted by IACGb to be used to compute packet signatures for the traffic destined for Hb from Ha. Depending on the signature method, which is specified in Aig field, PassKab may be either a secret key of an encryption system such as DES or a secret prefix/suffix for a message digest scheme such as MD4 or MD5.








To achieve the confidentiality of the pass-key during distribution, it is encrypted with IACGa's public key, which allows only IACGa to decrypt it. Note that the passkey is signed by IACGb before it is encrypted. This is to guarantee the integrity and authenticity of the key and prevent the possible modification or fabrication attack [68].

When IACG. receives a PASS-GRANT packet, it first verifies that H., Hb and TSa are indeed the same values that were sent in the PASS-REQUEST packet. It then verifies the PASS-REQUEST packet with the public key of IACGb, KUAcGb. Finally, it decrypts and stores the pass-key.

Next, IACGa may reply with ACK packet which notifies IACGb that the PASSGRANT packet has arrived safely and it successfully has decrypted PassKab.





ACK IACGa - IACGb: [IACGa, EpassKab[IACGb, TS]] (3.6)



ACK packet may be skipped for brevity even though it makes the interdomain authentication more complete.

In the meantime, both IACGa and IACGb create a new entry in their pass-table and IACGa forwards the pass-key to Ha by sending PASS-FORWARD packet.





PASS-FORWARD : IACGa -- Ha:

[IACGa, EKRIACGa.[Ha, Hb, TS., Alg, LT, EKUH.[EKRIACG[TSH., PassKb]]]13.7)








This packet is signed with IACGa's private key in order to be verified by H, with IACGa's public key. The pass-key is encrypted with He's public key. This prevents any other principal in the network from decrypting and acquiring the pass-key.

3.4.3 Packet Forwarding Phase

When the setup phase is completed, H, can begin communication. Each packet that Ha sends to Hb has to be accompanied by a pass. Since there are possibilities that more than one communication sessions are outstanding between Ha and Hb, a pass identifier should be included in those packets. In this scheme, TSa is used for this purpose. With it, the PASS routers can successfully identify an entry in their pass table.

A pass is computed as:



PASS = Fhash([Header, Data], PassKab)



where, Fhash is the signature function determined by the Aig field agreed on during the session initiation phase.

The resulting data packet has the following form which is also shown in Figure 3.3 with IP version 4:


DATA-PACKET Ha -- Hb: [Header, PassID, Pass, Data]


(3.8)








0 15 16 31 VERSION LENGTH TYPE OF SERVICE TOTAL LENGTH IDENTIFICATION FLAGS FRAGMENT OFFSET
TIME TO LIVE PROTOCOL HEADER CHECKSUM SOURCE IP ADDRESS
DESTINATION IF ADDRESS








DATA


Figure 3.3. IP Version 4 PASS data packet format Exiting source AD

When a packet with a pass arrives at IACG,, it has to be checked to show authorization to leave its local AD, ADa, as well as authenticity of its contents. IACGa first looks up its pass-table with the source, destination addresses and passkey identifier supplied by the packet. Successful look-up indicates the existence of exit authorization by IACG.. Next, IACG verifies the packet signature by re-computing the packet signature and comparing it to the pass attached to the packet. If the two values match, IACG can safely conclude that packet contents are authentic. The packet is now forwarded to the destination AD through the internetwork.








Entering destination AD

The operations performed by IACGb on any incoming data packet are exactly the same as those of IACG's; it checks authorization by indexing its pass-table with the source address, destination address and pass identifier, then re-computes the signature to verify the authenticity of the packet contents. A successfully checked packet is delivered to the destination end-system, Hb.

3.4.4 Session Revocation

A pass may be revoked for a couple of reasons: first, a normal expiration, which occurs when the Life Time condition is met, and secondly, an explicit revocation by an IACG. In the first case, a PASS-router simply deletes the corresponding entry from its pass-table. When a packet bearing a pass computed using an expired pass arrives at the PASS-router, it is promptly discarded since the table look-up fails. In the second case, an IACG may decide for some reason that a certain pass is no longer trusted and sends a REVOKE packet to the appropriate PASS-router. The following shows an example of REVOKE packet issued by IACGb and sent to IACGa. This is further explained in section 3.5.1.





REVOKE IACGb - IACGa : EKRIACGb[Ha, Hb, TSa, Cause] (3.9)



This concludes the description of the PASS protocol. An illustration of the protocol is shown in Figure 3.4. A dotted arrow from IACGa to Hb in the figure tells








ADa

ai
DATA(HaHb) REioCs AUTH-REQUEST
* {(Auihorizahon
CERT-REQ(IACGb) AuthenicadoTl
ER T(IA CGb)
PASS-REQUE



* PASS-GRANT PASS-FtIRWAR


............





T
(Autharization)
- ~EQ AG4)


Figure 3.4. An example of PASS scheme that the DATA packet is destined to Hb from Ha and trapped by IACG,. C.REQ represents the request for a public-key certificate to a local certification authority. C.IACG-A represents the public-key certificate of IACG.

3.5 Review of the Protocol

This section discusses several issues leading to the design of the PASS protocol, specifically in Internet environment. It also analyzes some security aspects of the protocol before assessing its cost.

3.5.1 Exception Handling

There are two situations when a pass-key becomes invalid in normal circumstance: i) when the time limit is exceeded, and ii) when a pass-key is revoked explicitly. There should be a proper mechanism to handle these situations appropriately.








Expiration of pass-key

LT is the lifetime of a pass-key to be used to expire the pass-key when the given condition is met. The simplest method is by way of timeouts, that is, an explicit time limit is negotiated at setup time and a pass-key is invalidated when the time limit is exceeded. A source host should invalidate the expired pass-key and should initiate a new session with the destination by first removing the entry from its pass list. IACG should also remove the expired pass-key from its pass list and reject any incoming packets with the expired pass identifier. While this is adequate for some types of connections, provisions for other methods of pass-key expiration may be necessary. These include limits on inactive periods, number of packets and bulk data transferred. Unfortunately, expiration based on limits other than just simple timeouts is not possible without maintaining states in IACGs. In order to expire pass-keys according to any of the above criteria requires that an IACG maintain running tally of packets, data bytes or the time of last packet arrival on a per pass-key basis. Revocation

Pass-key termination by explicit request from an IACG should be viewed as more of exception than the norm as, ordinarily, pass-keys are terminated by exceeding some limit negotiated at the time of issuance. An explicit pass-key revocation can happen when an IACG decides for some reason (in circumstances where there is suspicion of a pass-key's compromise) that a certain pass-key is no longer trusted. A REVOKE packet is sent to the counterpart IACG in this case and the entry should be removed








from both of the pass-key lists. Thereafter, both IACGs have to ensure that no more packet traffic belonging to the revoked pass-key connection passes through.

3.5.2 Design Issues in Internet Environment

There are several design issues which are related to the Internet environment: packet formats of PASS-IP with current and next version of IP standards, coverage of packet signature, and datagram fragmentation. PASS packet format

PASS data packet format with current IP (Version 4) standard is shown in Figure 3.3. Pass-ID and pass are stored in IP option field. Pass-ID takes 32 to 64 bits depending on the granularity of the timestamp, and pass takes either 64 bits with DES or 128 bits with MD5. Total packet length overhead will be 160 bits per packet when a 32 bit timestamp and the MD5 algorithm are used.

There are two specific headers that are used to provide security services in IPv6 [69]: the IP authentication header (Al) [70] and the IP encapsulating security payload header [71]. The IP Authentication Header, which is used to implement PASS scheme, is designed to provide integrity and authentication without confidentiality to IP datagrams. The lack of confidentiality ensures that implementations of the Authentication Header will be widely available on the Internet, even in locations where the export, import, or use of encryption to provide confidentiality is regulated. The Authentication Header has an authentication data field which can contain a variable number of 32-bit words. This field is used to contain pass and pass identifier as shown in Figure 3.5.








IP DATAGRAM


Figure 3.5. IP Version 6 authentication header containing pass

As shown in example IP datagram in Figure 3.5, the AH may appear after any other headers that are examined at each hop, and before any other headers which are not examined at an intermediate hop.

Coverage of packet signatures

A typical network-layer header contains addressing information such as source and destination end-system addresses, packet sequence number, packet length and other fields as the IP datagram header shown in Figure 3.3. Any header field not covered by the packet signature leaves a potential covert channel, since an intruder could trap a valid packet, change the unchecked field, and forward the modified copy without raising suspicion. We could protect against this by including the entire








network-layer header under the packet signature, but in most internetworking protocols there are some header fields (e.g., header checksum and time-to-live (TTL) field) that are modified by the intermediate routers, and hence cannot be included in the signature. Therefore, these fields should be masked when the packet signature is calculated.

Another issue has to do with the addressing information in the network header. Recall that pass-keys are issued on the basis of the source and destination end-system addresses. As described in previous section, each PASS data packet carries a pass identifier. This identifier is stored alongside the two end-system addresses in passtables of both IACGs. Since an IACG still has to consult its pass-table to look up the pass-key, it can (inexpensively) verify the Ha, Hb addresses as well. Therefore, it can be argued that end-system addresses and other information (e.g., type-of-service, transport protocol, etc.) that is stored in the pass-table entry does not need to be protected by the packet signature.

Fragmentation

In a number of internetworking protocols (e.g., IP) a router may have to fragment a packet if it cannot be transmitted in a single unit. Even though fragmentation is not a unique problem with PASS protocol, data signatures complicate the use of fragmentation since the fragments must appear to have been signed by H,., but the signatures would have to be computed by the fragmenting router. But with publickey signatures like PASS, this is impossible, since only the originating end-system








can compute the signature. Fragmentation is at best a necessary evil [72]; it is almost always better to set packet sizes at H,,, ,to make the best possible use of the available bandwidth and to provide acknowledgments for each transmission unit.

Although methods have been proposed for accommodating fragmentation while preserving data signatures [73], it is always better for the source end-system to avoid sending packets that will have to be fragmented since the overhead incurred by those methods are not trivial. One way of preventing fragmentation is to utilize one of the Internet Control Message Protocol (ICMP) messages [20]. In other words, ICMP Unreachable/Fragmentation Required error message can be used to find out the smallest maximum transmission unit (MTU) of the communication path. This ICMP Unreachable/Fragmentation Required error occurs when a router receives a datagram that requires fragmentation, but the don't fragment (DF) flag is turned on in the IP header. What we'll do is to send packets with the DF bit set. The size of the first packet we send will equal the MTU of the outgoing interface, and whenever we receive an ICMP Unreachable/Fragmentation Required error we'll reduce the size of the packet to the next smallest MTU defined in IP standard [74].

This can be done before actual exchange of PASS packets to decide the path MTU to the destination to avoid fragmentation. Maintaining known values in local storage will reduce the communication overhead.

3.6 Overhead Analysis

In this section, I address the impact of PASS protocol on the participating entities. The overhead can be considered in two different aspects: one for systems








and the other for network. Comparison with other schemes is provided at the end, too.

3.6.1 System Overhead

At the system level, overheads are associated with the additional storage requirement for the PASS software codes and related parameters . The overheads related to the storage of software codes vary according to the type of internetwork entity (an end-system or an access control gateway) and to the programming paradigms employed in the implementation. These topics are beyond the scope of this paper and are not discussed further.

On the other hand, maintaining pass-tables demands additional storage in IACGs and end-systems. Each IACG keeps valid pass-list which at minimum consists of source end-system address, destination address, pass identifier, pass-key, lifetime, and signing algorithm. Due to the limited availability of memory in IACG, it is required to keep the size of the pass-list as small as possible. This in turn requires an efficient maintenance of pass-list by removing invalid pass entry from the list in a timely manner. This depends on the efficiency of the pass revocation mechanism. Additional information such as the arrival time of the last valid packet might be needed to monitor the activities of communication sessions for detecting idle ones.

An end-system must also keep a list of active passes. This pass-list is essentially the same as the IACG's pass-list. IACGs and end-systems may need to save publickey certificates of peer entities in local and remote ADs for faster access of public keys of them.








3.6.2 Network Overhead

Session initiation

The number of additional packets required for establishing an external session between H, and Hb can be traced from the sequence of events explained in previous section. It shows that there are 10 extra packets required before H. is allowed to go into the packet forwarding phase. The first two packets, DATA and REJECT packet, can be skipped if the source end-system knows that the destination end-system is in remote AD and it has the address of local IACG, IACG,. Moreover, four packets involved in getting public-key certificates can also be saved if both IACGs find each other's public-key certificates in their local cache. Therefore, only four additional packets are needed in session initiation phase in the best case. Packet forwarding

Extra packets are generated only when there is a failure in matching the pass of a packet transmitted between two peer entities. One extra packet is generated if the pass of a packet from H does not match that generated in IACG,. Two extra packets will be generated if the pass of a packet from H does not match that generated in IACGb. Other overhead in this phase include the additional fields in data packets, table look-ups in IACGs, and pass computation in end-systems and IACGs. The pass identifier is 32-bit quantity which is typical for a timestamp in internet protocols. The size of the pass depends on the signature method agreed by Algor field in PASS-GRANT packet. For now, it is either 64 bit DES key or 128 bits for MD5 secret prefix/suffix.








3.6.3 Comparison with Other Schemes

First, the number of extra packets generated for each external session in PASS scheme, which is at most 10, is substantially smaller than the other two schemes.

The author of the VISA scheme illustrated the visa acquisition phase for a pairwise connection with an example and concluded: 'For the illustration given above, a minimum of 15 extra packets are generated before the first user packet gets through, not including the packets that comprise the authorization/authentication conversations between hosts and ACSs. Note that all of these control packets will be of minimal length.' That is, this scheme may introduce well over 20 extra packets in session initiation phase

With Iqbal's scheme, there are 21 extra packets required before the local host was allowed to go into the packet control mode to transport packets to the remote network. Moreover, this number of extra packets is derived with the assumption that the transit network gateways do not enforce the access control procedures. Obviously, if the number of interconnected networks increases and the access control procedures are implemented in each of the transit networks, the overhead will increase dramatically.














CHAPTER 4
INTER-DOMAIN AUTHENTICATION WITHOUT AN ARBITER


4.1 Motivation

Most of existing interdomain (or inter-realm) authentication protocols assume the existence of a trusted third party as an arbiter between two authenticating principals [31, 33, 34, 46]. That is, they assume there is a trusted Authentication Server which shares a unique master key with each of the principals. The AS is capable of producing good session keys and sending them securely on the requests of principals. This assumption simplifies the interdomain authentication problem into a intra-domain authentication.

Other interdomain authentication protocols are either based on a proxy (or delegation) concept or using hierarchical authentication. The former achieves the interdomain authentication through a chain of trust between authentication servers. Any broken link on the chain might annihilate the service. The latter approach suggests a hierarchy of access control servers which can perform interdomain authentication through cascaded authentications at multiple levels [46]. However, it is not always reasonable to assume the existence of a trusted authentication server between any two ADs in the internet environment. More often, there is no trusted third party between ADs which need to authenticate each other in internetworks.








The interdomain authentication protocol presented here does not require any trusted third party in between. This interdomain authentication protocol, which is essential in interdomain access control schemes, is based on a public key encryption system. Public keys of peer principals are provided by ISO standard 9594-8/ITU-T X.509 Directory Authentication Service [37]. This removes the need for a globallytrusted authentication server (AS) which is not quite realistic in internetwork environments. This also alleviates the security threats found in Iqbal's scheme [30] where RSA private keys should be shared between peer communicating entities.

Some of the important design principles which differentiate interdomain authentication from intra-domain authentication are listed below:


9 The message complexity and encryption overhead should be reduced as much

as possible so that it is feasible to implement in interdomain communication.


* The use of timestamps, although effective in reducing the message complexity,

should be used carefully in an interdomain authentication, since the existence of proper clock synchronization among multiple machines is much more difficult

to guarantee if the machines reside in different administrative domains.


* Interdomain authentication should be transparent to principals. That is, the

mechanisms designed for interdomain authentication should not interfere with the existing intra-domain authentication mechanisms at local machines. Any addition or modification of features for interdomain authentication should only

affect the involved parties such as gateways.








In the next section, several ongoing efforts on providing public-key certificate infrastructures are introduced. The descriptions of ITU-T X.509 directory authentication service and a new interdomain authentication protocol based on the service are given in the following sections.

4.2 Public-Key Certificate Infrastructure

When using public key digital signature authentications each entity requires a public key and a private key. The public-key certificate is an essential part of a digital signature authentication mechanism. Certificates bind a specific entity's identity (be it host, network, user, or application) to its public keys and possibly other security-related information such as privileges, clearances, and compartments. Authentication based on digital signatures requires a certificate authority to create, to sign and properly to distribute certificates [751.

4.2.1 Certificate Authorities

Certificates require an infrastructure for generation, verification, management and distribution. The Internet Policy Registration Authority (IPRA) [76] has been established to direct this infrastructure for the Internet Engineering Task Force (IETF). The IPRA certifies Policy Certification Authorities (PCA). PCAs control Certificate Authorities (CA) which certify users and subordinate entities. Current certificate related work includes the Domain Name System (DNS) Security Extensions [77] which will provide signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working group is specifying an Internet profile for X.509 certificates. There is also work going on in industry to develop X.500 Directory Services which would provide








X.509 certificates to users. The U.S. Post Office is developing a certificate authority hierarchy. The National Institute of Standards and Technology (NIST) Public Key Infrastructure Working Group has also been doing work in this area. The Department of Defence (DOD) Multi Level Information System Security Initiative (MISSI) program has begun deploying a certificate infrastructure for the U.S. Government. Alternatively, if no infrastructure exists, the Pretty Good Privacy (PGP) Web of Trust certificates can be used to provide user authentication and privacy in a community of users who know and trust each other.

4.2.2 X-509 Directory Authentication Service

ITU-T recommendation X.509 is a part of the X.500 series of recommendations that defines a directory service. The directory is, in effect, a server or distributed set of servers that maintains a database of information about principals. The information includes a mapping from user name to network address, as well as other attributes and information about the users. X.509 defines a framework for the provision of authentication services by the X.500 directory to its users. The directory may serve as a repository of public-key certificates of the type discussed below. Each certificate contains the public key of a user and is signed with the private key of a trusted certification authority.

Public-key certificate

The heart of the X.509 scheme is the public-key certificate associated with each user. These user certificates are assumed to be created by some trusted certification authority (CA) and placed in the directory by the CA or by the user. The directory








server itself is not responsible for the creation of public keys or for the certification function; it merely provides an easily accessible location for users to obtain certificates.

The standard uses the following notation to define a certificate:



Y << A >>= Y{V, SN, AI, CA, TA, A, Ap}



where, Y << A >> represents the certificate of an user A issued by a certification authority Y. Y{I} represents the signing of I by Y, which consists of I with an enciphered hash code appended. The constituents V, SN, AI, CA, TA, A, and Ap represent a version number, serial number, algorithm identifier, issuer CA, period of validity, user identifier, and user's public key, respectively. The CA signs the certificate with its private key. If the matching public key is known to a user, then the user can verify that a certificate signed by the CA is valid. Certificate authority

Because certificates are unforgeable, they can be placed in a directory without the need for the directory to make special efforts to protect them. If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates can be placed in the directory for access by all users. In addition, a user can transmit his or her certificate directly to other users. In either case, once a principal B is in possession of the other principal A's certificate, B has confidence that messages it encrypts with A's public key will be secure from eavesdropping and that messages








signed with A's private key are unforgeable. If there is a large community of users, it may not be practical for all users to subscribe to the same CA; because it is the CA that signs certificates, each participating user must have a copy of the CA's own public key in order to verify signatures. This public key must be provided to each user in an absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical to have a number of CAs, each of which securely provides its public key to some fraction of the users.

Now suppose that A has obtained a certificate from a certification authority X1 and B has obtained a certificate from a CA X2. If A does not securely know the public key of X2, then B's certificate, issued by X2 is useless to A. A can read B's certificate, but A cannot verify the signature. However, if the two CAs have securely exchanged their own public keys, the following procedure will enable A to obtain B's public key.


1. A obtains, from the directory, the certificate of X2 signed by X1. Because A

securely knows X1's public key, A can obtain X2's public key from its certificate

and verify it by means of X's signature on the certificate.


2. A then goes back to the directory and obtains the certificate of B signed by

X2. Because A now has a trusted copy of X2's public key, A can verify the

signature and securely obtain B's public key








A has used a chain of certificates to obtain B's public key. In the notation of X.509, this chain is expressed as:


X,1 << X2 >> X/2 << B >>



In the same fashion, B can obtain A's public key with the reverse chain:



X2 << X >> x, << A >>



This scheme need not be limited to a chain of two certificates. An arbitrarily long path of CAs can be followed to produce a chain. A chain with N elements would be expressed as:



X, << X2 >> X2 << X3 >> ... << XN >> XN << B >>



In this case, each pair of CAs in the chain (Xi, Xi+,) must have created certificates for each other. All these certificates of CAs need to appear in the directory, and the user needs to know how they are linked in order to follow a path to another user's public-key certificate. X.509 suggests that CAs be arranged in a hierarchy, so that navigation is straightforward.

Certificate authority hierarchy

Figure 4.1 is an example of such a hierarchy. The connected circles indicate the hierarchical relationship among the CAs; the associated boxes indicate certificates



























Figure 4.1. X.509 CA hierarchy: A hypothetical example

maintained in the directory for each CA entry. The directory entry for CA X includes two types of certificates:


* Forward certificates: certificates of X generated by other CAs


* Reverse certificates: certificates generated by X that are the certificates of other

CAs

In this example, user A can acquire the following certificates from the directory to establish a certification path to B:


X << W >> W << V >> V << Y >> Y << Z >> ,Z << B >>



When A has obtained these certificates, it can unwrap the certification path in sequence to recover a trusted copy of B's public key. Using this public key, A can








send encrypted messages to B. If A wishes to receive encrypted messages back from B, or to sign messages sent to B, then B will require A's public key, which can be obtained from the following certification path:


Z << Y >> Y << V >> V << W >> W << X >> X << A >>



B can obtain this set of certificates from the directory, or A can provide them as part of its initial message to B.

Recall from the previous description that each certificate includes a period of validity, much like a credit card. Typically, a new certificate is issued just before the expiration of the old one. In addition, it may be desirable on occasion to revoke a certificate before it expires for one of the following reasons:


1. The user's secret key is assumed to have been compromised.


2. The user is no longer certified by this CA.

3. The CA's secret key is assumed to have been compromised.

Each CA must maintain a list consisting of all revoked but not expired certificates issued by that CA, including both those issued to users and to other CAs. These lists should also be posted on the directory. Each certificate revocation list posted to the directory is signed by the issuer and consists of the issuer's name, the date the list was created, and an entry for each revoked certificate. Each entry consists of the serial number of a certificate and revocation date for that certificate. When a user receives a certificate in a message, the user must determine whether the certificate








has been revoked. The user could check the directory each time a certificate is received. To avoid the delays (and possible costs) associated with directory searches, it is likely that the user would maintain a local cache of certificates and lists of revoked certificates.

4.3 A Secure and Efficient Interdomain Authentication Protocol

Central to the problem of authenticated key exchange are two issues: confidentiality and timeliness. To prevent masquerade and to prevent compromise of session keys, essential identification and session key information must be communicated in encrypted form. This requires the prior existence of secret or public keys that can be used for this purpose.

This protocol is based on the assumption that the two parties know each other's public key, either by obtaining each other's public-key certificates from an X.509 directory or because the certificate is found in the local cache from some previous use. The second issue, timeliness, is important because of the threat of message replays. Such replays, at worst, can allow an opponent to compromise a session key or successfully impersonate another party. At minimum, a successful replay can disrupt operations by presenting parties with messages that appear genuine but are not.

4.3.1 Notation

The following notation is used throughout the description of the protocol. The notations here are used to maintain the conformity to the BAN logic [42, 47].

. A{ I} denotes signing of I with A's private key.














Figure 4.2. An interdomain authentication protocol

* {IIK denotes encryption of I with a key K. K can be either a public key in

public key system or a secret key with a conventional encryption system.


� I ab denotes a shared key between principals A and B.


4.3.2 The Protocol

The message flow of the protocol is shown in Figure 4.2 and the details of the messages are shown as follows:


Message 1 A--B: A,A{B,TS}

Message 2 B -- A: B,B{A, TSb, {B{TS.,Kab}lK.}

Message 3 A - B: A, {B, TSb}Kb



where, A{I} represents information signed by encrypting it with A's private key. {I}K represents information encrypted by A's public key. Principal A initiates the authentication by sending B a timestamp TSa along with the identity of itself and that of the desired destination principal. The destination address and a timestamp TSa are signed with A's private key to provide the authentication of this message. After B receives this message, it generates a session key Kb and sends it to A along with the timestamp sent by A and a new timestamp TSb. The session key is signed








first with the private key of B and then encrypted with the public key of A. A then gets the session key by first decrypting it with its private key and then with B's public key. Finally, A sends an acknowledgment packet which is encrypted with the session key, Kab.

4.3.3 Informal Analysis

The first message establishes:


9 the identity of A,


* that the message was generated by A, * that the message was intended for B,


e the integrity of the message, and


e the freshness of the message


At a minimum, the message includes a timestamp TSa and the identity of B, and is signed with A's private key. The timestamp consists of an optional generation time and an expiration time. This prevents delayed delivery of messages. A nonce, Na5, can be used to detect replay attacks. The nonce value must be unique within the expiration time of the message. Thus, B can store the nonce until it expires and reject any new messages with the same nonce. Here, TSa can be considered as a nonce which is useful when it is difficult or impossible to have synchronized system clocks. B now can safely believe that this message is generated by A since only A has the private key to sign this message.








The second message establishes the following:


" the identity of B,


* that the reply message was generated by B,


* that the message was intended for A


" the integrity of the reply message,


" the freshness of the reply message, and


* the confidentiality of the session key, Kab


The session key, K,,b, is first signed with B's private key and then encrypted with A's public key. The former provides the authenticity of the session key while the latter guarantees the confidentiality of the key since only A can decrypt it. The order of signing and encryption is important here, as will be further explained later.

The last message confirms B that A has received the session key safely. The timestamp TSb provides the freshness proof with B.

4.4 Formal Protocol Analysis Using BAN Logic

In this section, the proposed protocol is analyzed by using BAN Logic. BAN Logic is a formal protocol verification method to assure the correctness of an authentication protocol. Each message of the protocol is converted into the idealized form according to the method suggested by BAN logic [47] and is shown below:











Message 1 A -- B: A{TS}

Message 2 B -- A: B{TSb, {B{TS, A K , B}}K.}

Message 3 A--+B: {B, TSbA-4B}K.


The idealized messages correspond quite closely to the messages shown in the original protocol. The cleartext communication has been removed throughout since it provides no guarantees of any kind. The sender information from the first two messages has been removed since it does not contribute to the beliefs of the recipient. As usual, the timestamps TS. and TSb are viewed simply as nonces in the idealized protocol. Message 2 may tell A, who knows the key K"., that Kb is a key to communicate with B.

The initial assumptions of the protocol in BAN logic notation are:


K;'l
Key 1.A -KP.' A 2.B g- B

3.A B 4.B A KK
5.A (B k A + B) 6.B A'- B



Freshness L.A O (TS,) 2.B O (TSb)
The first four assumptions in the key group tells that each principal knows its own secret key and the other's public key. The next two show that B has invented a new key, and that A trusts B to invent the good keys. The two assumptions in the








freshness group tell that each principal can verify and thus believes the freshness of timestamp it generated.

The formal proof of the protocol using the postulates of BAN logic is presented as follows. First, A sends a signed timestamp to B and B sees it:



B -A{TS,,}



This and the fourth key assumption gives the following through the message-meaning rules:



B A, TS



And B can decrypt this message since it has A's public key.



B -a TS,



Similarly, the message 2 gives:


A TS

A f {BITS,,, A b B}},,.


A can decrypt the last component shown above, and we get:








A o B{TS,A'AP B}



This and the third key assumption give the following through the message-meaning rules:



A I B ,, A4 B



From the freshness assumption, A knows that TSa is fresh. This guarantees the freshness of the shared key A , B. This freshness and the belief established just before give the following via the nonce-verification rule:



A B IF A '5 B



Finally, this and the assumption of B's jurisdiction over A JV B together give:



A A K B



Message 3 gives the following through the freshness and nonce-verification rules:


B I A A$K B










In conclusion, the final beliefs of both principals achieved by this protocol are:



A A B B A % B
A B A' B B A A +- B


which are exactly the formalized goals of authentication for all authentication protocols as recommended by the authors of BAN Logic. These goals are achieved with only three messages.

Note that the session key in the second message is signed first with B's private key before it is encrypted. That is because although Kb has been transferred in a signed message, there is no evidence to suggest that the sender is actually aware of the data that he sent in the private part of the message. This corresponds to a scenario where some third party intercepts a message and removes the existing signature while adding his own, blindly copying the encrypted section within the signed message. In other words, the last part of beliefs cannot be established without signing before the encryption of the session key [68].

4.5 Preventing Replay Attacks

Since the destination address B in the last message guarantees the uniqueness of his own timestamp TSb, he can be sure that this message is linked uniquely to this instance of the protocol in a timely fashion. Consider an attack scenario with a version of our authentication protocol which does not include B in the last message as ITU-T X.509 three way protocol [37]. This version of the protocol just sign the













eMessage 6


Message:


Figure 4.3. A scenario of a replay attack

last message with A's private key instead of encrypting it with the session key. One might hope that the use of TSb would be sufficient to link the third message to the first, since TSb links the last two messages and TSa links the first two messages. The error here is that TSb alone does not link the last two messages, and this allows an intruder C to replay one of A's old messages.

The following concrete exchange which is also shown in Figure 4.3 illustrates the flaw. The timestamp TSb is not secret, and there is nothing to prevent C from using the same value in an instance of the protocol between A and C. If C is able to cause A to attempt authentication with C at the required time, the following sequence of messages can result. The intruder first contacts B:



Message 1 C - B: A,A{B, TS


This is an old message originally sent by A. Remember that B is not presumed to


Message




Full Text

PAGE 1

ENFORCING ACCESS CONTROL POLICIES IN INTERNETWORK ENVIRONMENTS By HYUN PARK A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 1996

PAGE 2

To God, my parents, and my wife, Haewon.

PAGE 3

ACKNOWLEDGMENTS First of all, I would like to express my sincere gratitude to my dissertation advisor, Dr. Randy Chow, for his guidance and support, which made the completion of this work possible, and also for his philosophical advice on both my academic and non-academic life, which made me more mature, personally and scholastically. I also want to express my thanks to Dr. NewmanWolfe for his numerous fruitful discussions which provided deeper insights into some parts of this research. Thanks also go to Dr. Sartaj Sahni, Dr. Jih-Kwon Peir, and Dr. Haniph A. Latchman for their many constructive questions and witty suggestions for my research work. Furthermore, I wish to thank all the faculty members in CISE department who stimulated my interests and equiped me with the methodology to explore the magic world of computer sciences. Special thanks go to my parents for their continued support, spiritual and financial. They have never lost great confidence in my ability throughout the years at the University of Florida. None of my efforts would have been fruitful without their unparalleled love. Finally, words axe never enough to express my gratitude to my lovely wife, Haewon, for her constant love, patience, and encouragement during difficult times, and for her unreserved devotion to the care of our family. Praise God for all He has done for me! iii

PAGE 4

TABLE OF CONTENTS ACKNOWLEDGMENTS iii LIST OF FIGURES vii ABSTRACT viii CHAPTERS 1 INTRODUCTION 1 1.1 Computer Security 1 1.1.1 Objectives 1 1.1.2 Security Services 2 1.2 Internetwork Security 5 1.2.1 Security Attacks 5 1.2.2 Internetwork Security Models 7 1.2.3 Access Control in Internetwork 9 2 BACKGROUND AND LITERATURE REVIEW 14 2.1 Preamble 14 2.2 Internetwork Access Control 14 2.2.1 Firewall Approach 16 2.2.2 Distributed Systems Approach 18 2.2.3 Packet-Level Authentication Approach 20 2.3 Interdomain Authentication 22 2.3.1 Authentication Protocols 24 2.3.2 Interdomain Authentication Protocols 27 2.3.3 Formal Protocol Analysis and Evaluation 29 2.4 Secure Control of Transit Internetwork Traffic 29 2.4.1 Issues in Internetwork Environments 30 2.4.2 Policies 31 2.4.3 Controlling Transit Internetwork Traffic 35 3 PACKET-LEVEL ACCESS SECURITY SCHEME 44 3.1 Motivation 44 iv

PAGE 5

3.2 Network Environment 46 3.3 Components of PASS 47 3.3.1 Internet Access Control Gateways 47 3.3.2 Pass Key 49 3.3.3 PASS End-Systems 51 3.3.4 Certification Authorities 52 3.4 Protocol Description 54 3.4.1 Notation 55 3.4.2 Session Initiation Phase 56 3.4.3 Packet Forwarding Phase 62 3.4.4 Session Revocation 64 3.5 Review of the Protocol 65 3.5.1 Exception Handling 65 3.5.2 Design Issues in Internet Environment 67 3.6 Overhead Analysis 70 3.6.1 System Overhead 71 3.6.2 Network Overhead 72 3.6.3 Comparison with Other Schemes 73 4 INTER-DOMAIN AUTHENTICATION WITHOUT AN ARBITER .... 74 4.1 Motivation 74 4.2 Public-Key Certificate Infrastructure 76 4.2.1 Certificate Authorities 76 4.2.2 X-509 Directory Authentication Service 77 4.3 A Secure and Efficient Interdomain Authentication Protocol 83 4.3.1 Notation 83 4.3.2 The Protocol 84 4.3.3 Informal Analysis 85 4.4 Formal Protocol Analysis Using BAN Logic 86 4.5 Preventing Replay Attacks 90 4.6 Variations of the Protocol 93 4.6.1 OneWay Authentication 93 4.6.2 Mutual Authentication with OneWay Pass 95 5 SECURE CONTROL OF TRANSIT INTERNETWORK TRAFFIC ... 97 5.1 Motivation 97 5.2 Security Issues in Transit Control 98 5.2.1 Security Threats 98 5.2.2 Cryptographic Tools 99 5.3 Description of Security Mechanisms 102 5.3.1 Secure Distribution of PoHcy Terms 103 5.3.2 Route Setup Phase 105 5.3.3 Packet Forwarding Phase 108 V

PAGE 6

5.4 Cost of Security Mechanisms Ill 5.4.1 Per Packet Signature Overhead 112 5.4.2 Packet Length Overhead 114 5.4.3 Setup Overhead 114 5.4.4 Other Per Packet Processing Costs 115 6 CONCLUSIONS AND FUTURE WORK 116 6.1 Internetwork Access Control 116 6.2 Interdomain Authentication 117 6.3 Secure Control of Transit Internetwork Traffic 118 APPENDICES A INTEGRATION OF PASS WITH GTGB 120 A.l GTGB Functionality 120 A.2 Configuration of Gemini-UF GTGB Testbed 123 A. 2.1 PrivateTo-Private Secure Connections 124 A. 2. 2 PrivateTo-Public Connections 125 A.3 Integration of PASS into GTGB Testbed 126 A.3.1 Coexistence of PASS and GTGB 126 A.3.2 Interactions between PASS and GTGB 128 B ACRONYMS 131 REFERENCES 132 BIOGRAPHICAL SKETCH 138 VI

PAGE 7

LIST OF FIGURES 1.1 Four categories of security attacks 6 1.2 A model for internetwork security 8 1.3 Model for internetwork access security 10 3.1 A simplified state diagram for a source lACG 50 3.2 An illustration of two communicating PASS ADs 55 3.3 IP Version 4 PASS data packet format 63 3.4 An example of PASS scheme 65 3.5 IP Version 6 authentication header containing pass 68 4.1 X.509 CA hierarchy: A hypothetical example 81 4.2 An interdomain authentication protocol 84 4.3 A scenario of a replay attack 91 A.l The network configuration of Gemini-UF Testbed 124 vii

PAGE 8

Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for Doctor of Philosophy ENFORCING ACCESS CONTROL POLICIES IN INTERNETWORK ENVIRONMENTS By Hyun Park August 1996 Chairman: Dr. Randy Chow Major Department: Computer and Information Science and Engineering Internetwork environments are inherently vulnerable to security threats due to their openness, the nonexistence of a centralized management authority, and insecure communication channels. Moreover, increasing internetwork applications frequently require connecting administrative domains with competing interests. In this environment, unauthorized access to network resources is an issue of growing concern. However, existing resource access control schemes either have security flaws or suffer from inconvenience and inflexibihty. The primary objective of this research is to develop a secure and eflficient internetwork access control scheme. Packet-level access security scheme (PASS) is a viii

PAGE 9

policy enforcement mechanism for stub domains. In using PASS, a unique pass-key is assigned to each communication session after both end-systems are authorized and authenticated. Any valid packet should include a proper pass in it to be verified by access control gateways. The security and performance of this protocol has been assessed and the results are compared with those of other schemes. PASS uses a new interdomain authentication protocol that utilizes ITU-T X.509 directory authentication service as the public key provider. This removes an unrealistic assumption about the availability of a trusted third party used in most other existing protocols. The authentication goals of the protocol are verified by using BAN logic. Two variations of this protocol are given for the situations that require one-way authentication and one-way pass. To complement the policy enforcing scheme, a secure transit control mechanism is proposed. Controlling access to network resources in intermediate domains is closely related to packet routing. Therefore, two policy-based routing protocols are investigated first and security mechanisms are provided to the Inter-Domain Policy Routing protocol (IDPR). The cost of the added security is analyzed for several modes of transit packet verification. In summary, this dissertation is devoted to the investigation of three main issues in internetwork access control. First, a secure and efficient stub domain access control scheme is proposed. Next, a new interdomain authentication protocol is presented to be used in PASS. Finally, a secure transit control scheme is proposed by adding security mechanisms to IDPR. ix

PAGE 10

CHAPTER 1 INTRODUCTION 1.1 Computer Security Computer security is assuring the confidentiality, integrity, and availability of components of computing systems. The three principal pieces of a computing system subject to attacks are hardware, software, and data. These three pieces, and the communications between them, constitute the basis of computer security vulnerabilities. In order to realize the computer security, a secure computer system needs to provide security services to its users. 1.1.1 Objectives The principal objectives of computer security can be more specifically characterized as the protection of confidentiality, integrity, and availability of computing system components, as discussed below. • Protecting data confidentiality means preventing unauthorized accessing of computing system assetts. The type of access is read-type access such as reading, viewing, printing, or even just knowing the existence of an object. • Protecting data integrity means preventing unauthorized modification of computing system assetts. In this context, modification includes writing, changing, changing status, deleting, and creating. 1

PAGE 11

2 • Protecting data availability means preventing denial of service. An authorized user should not be prevented from accessing those objects to which he or she or it has a legitimate access right. 1.1.2 Security Services To achieve these computer security objectives, a secure computer system needs to provide a set of computer security services, with which the users can protect their data and the system can protect its resources appropriately, as follows. • Authentication is verifying the identity of a user or a process on behalf of him. In simple words, an authentication service tries to answer the question, who are you ? • Authorization is controlling all accesses of users to data, according to some pre-determined security policies. In simple words, an authorization service tries to answer the question, what can you access and how ? • Auditing is recording occurrences of all security-relevant events in an audit log. In simple words, an auditing service tries to answer the question, what have you done ? Authentication The authentication service is usually the first service that a user will experience before he can proceed to perform other computing tasks. Since all other security services depend on authentication, an authentication service must be reliable and robust. Password is the most common approach to authenticate the identity of a

PAGE 12

3 user. Password is a secret character string kept by both a user and the authentication service. Password security has been extensively researched and many guidelines of selecting good passwords that are hard to guess have been proposed [1, 2]. The secrecy and integrity of the system password file which stores the passwords of all the users must be fully protected. Some modern computer systems use smart cards [3] to authenticate users. A smart card is a device held by a user and embedded with a microprocessor, memory, and algorithms to compute an identification string with the user's password as its input. The advantages of smart cards are that the authentication process is more secure than simply using user passwords and a user can login to a computer system from anywhere if there is a smart card reader (since the encryption algorithm and mechanism are provided by the smart card, rather than by the machine). More advanced authentication methods use biometric authentication devices [4] to recognize a user's personal characteristics like his/her voice, retina, or fingerprints. Showing the greatest promise of authentication, biometric advices need advanced speech or image processing technology. Their high costs are only justified where the benefits they provide are absolutely required. Authorization Each access of a user, or a process executing on behalf of him, to some data storage needs to be controlled by the authorization service. To describe how data access should be mediated, explicit and well-defined security policies or access control policies need to be defined. An access control policy consists of a set of rules used by the system to determine whether an access attempt by a user to a specific data

PAGE 13

4 storage should be granted or denied. A security model or access control model is a formal representation (by mathematical notations and formalisms) of the security policies enforced by the system. It offers a means to depict how each data access is regulated by the authorization service. Note that a security policy is defined to reflect the security requirements of an organization or its users, and should be established independent of any security models. A security model describes how each access decision is determined, in order not to violate the security policy. Naturally, it is desirable to choose a security model that can enforce a wide variety of security pohcies. A security model only provides an abstract concept of enforcement of security policies. In practice, it needs to be realized by a security mechanism or access control mechanism that consists of hardware and software features, operating functions, and management procedures to perform the activities of an authorization service. One security model may be implemented by several distinct types of security mechanisms, with each having its advantages and disadvantages from different viewpoints of management. Regardless of how powerful a security model is, operation efficiency of a security mechanism and ease of its management framework are crucial to the applicability of a security model. Auditing The auditing service can be thought as the last defense line of a secure computer system, because once other security services fail and a security violation occurs, the auditing log can be reviewed and examined to trace the responsible users and reveal

PAGE 14

5 the imperfection of security mechanisms. The latter often provides the most valuable information for improving the security services of a computer system. The capability of selecting the audit events to be recorded is necessary to minimize the expense of auditing and to allow eflBcient analysis. For obvious reasons, the audit data itself must be protected from unauthorized modification and destruction. 1.2 Internetwork Security The requirements of information security within an organization have undergone a major change in the last several decades with the introduction of distributed systems and the use of networks and communication facilities for carrying data between terminal user and computer and between computers. Network security measures are needed to protect data during their transmission. In fact, the term network security is somewhat misleading, because virtually all business, government, and academic organizations interconnect their data processing equipment with a collection of interconnected networks. Such a collection is often referred to as an internetworld , and internetwork security will be a more suitable term in this case. 1.2.1 Securitv Attacks The types of attacks on the security of a computer system or network are best characterized by viewing the function of the computer system as providing information. In general, there is a flow of information from a source, such as a file or a region of main memory, to a destination, such as another file or a user. This normal flow is ^Not to be confused with the term (DARPA) Internet, which refers to a specific collection of networks that has become something of a global public networking utility. The Internet may be one of the facilities used by an organization to construct its internetwork.

PAGE 15

6 O O Souice Destination (a) Normal Flow o o o o (b) Interruption (c) Interception o o o o o o (d) Modirication (e) Fabrication Figure 1.1. Four categories of security attacks depicted in Figure 1.1(a). The remaining parts of the figure show the following four general categories of attack: • Interruption is when an asset of the system is destroyed or becomes unavailable or unusable. This is an attack on availability. Examples include destruction of a piece of hardware, such as a hard disk; the cutting of a communication line; or the disabling of the file management system. • Interception is when an unauthorized party gains access to an asset. This is an attack on confidentiality. The unauthorized party could be a person, a program, or a computer. Examples include wiretapping to capture data in a network, and the illicit copying of files or programs. • Modification is when an unauthorized party not only gains access to but tampers with an asset. This is an attack on integrity. Examples include changing

PAGE 16

7 values in a data file, altering a program so that it performs differently, and modifying the content of messages being transmitted in a network. • Fabrication is when an unauthorized party inserts counterfeit objects into the system. This is an attack on authenticity. Examples include the insertion of spurious messages in a network or the addition of records to a file. A useful categorization of these attacks is in terms of passive attacks and active attacks. Examples of passive attacks are eavesdropping or monitoring of transmissions. The goal of the opponent is to obtain information that is being transmitted. Two types of attacks are involved here: release of message contents and traffic analysis. Active attacks involve some modification of the data stream or creation of a false stream and can be subdivided into four categories: masquerade, replay, modification of messages, and denial of service. The security services discussed in the previous section encounter these security attacks and make use of one or more security mechanisms to provide the services. 1.2.2 Internetwork Security Models A general model for internetwork security is shown in Figure 1.2. Messages are transferred from one party to another across an internetwork. The two parties, who are the principals ^ in this transaction, must cooperate for the information exchange to take place. A logical information channel is established by defining a ^The entities in a networked or distributed system that can be distinctly identified are collectively referred to as principals.

PAGE 17

8 Message . Secret information Message Secret information Security-related transformation Figure 1.2. A model for internetwork security route through the internetwork from source to destination and by the cooperative use of communication protocols (e.g., TCP/IP) by the two principals. Security aspects come into play when it is necessary or desirable to protect the information transmission from an opponent who may present a threat to confidentiality, authenticity, and so on. All the techniques for providing security have two components: • A security-related transformation on the information to be sent. Examples include the encryption of the message, which scrambles it so that it is unreadable by the opponent, and the addition of a code based on the contents of the message, which can be used to verify the identity of the sender. • Some secret information shared by the two principals and, hopefully, unknown to the opponent. An example is an encryption key used in conjunction with the

PAGE 18

9 transformation to scramble the message before transmission and unscramble it on reception. A trusted third party may be needed to achieve secure transmission. For example, a third party may be responsible for distributing the secret information to the two principals while keeping it from any opponent. A third party may be needed to arbitrate disputes between the two principals concerning the authenticity of a message transmission. This general model shows us that there are four basic tasks in designing a particular security service: 1. Design an algorithm for performing the securityrelated transformation. The algorithm should be such that an opponent cannot defeat its purpose. 2. Generate the secret information to be used with the algorithm. 3. Develop methods for the distribution and sharing of the secret information. 4. Specify a protocol to be used by the two principals that makes use of the security algorithm and the secret information to achieve a particular security service. 1.2.3 Access Control in Internetwork There are other security-related situations of interest that do not neatly fit in this model but that are important in internetwork environment. A general model of these situations is illustrated by Figure 1.3, which reflects a concern for protecting an information system from unwanted access.

PAGE 19

10 Information System Computing Resources Internal Security Control Figure 1.3. Model for internetwork access security Traditional internetworks often ignore the issue of interdomain access control, either because they connect organizations within a large administrative unit such as university or government, or because they connect research institutions with little need to limit information flow. With increasing internetwork applications, emerging internetworks are frequently required to connect administrative domains, or ADs^, that may have competing interests. In this environment, unauthorized access to network resources is an issue of growing concern since security threats and the damage associated with such unauthorized accesses, can be very high. Therefore, ADs should be able to interconnect without exposing their internal resources to unrestricted external access. Moreover, internetwork components should be able to control incoming and outgoing traflfic by specifying or constraining the ADs to, and through which, the traffic can flow. Therefore, it is necessary to implement an access control mechanism to protect these resources. To do this, all of the access control requirements should be specified clearly. ^An AD is defined as a collection of network resources under control of a single administrative entity [5] Opponent < Access channel (tjatekeeper function/

PAGE 20

11 Access control requirements Due to the characteristics of the internetwork discussed above, some security measures are required to protect resources from unauthorized accesses. However, in an internetwork, the goal is not simply to prohibit access by outsiders; some outside access is explicitly desired. The goal is to support access to certain machines, services, and processes, while preventing access to all other internal facilities. Therefore, it is not desirable that externally accessible facilities be physically isolated from all strictly internal resources for this would interfere with internal access to local information and resources. Similarly, requiring that all internal facilities adopt additional security measures to cope with external connections may interfere with internal communication and resource sharing. This measure also requires global knowledge of all interconnections. Therefore, it is desirable to implement logical networks that can be isolated from one another yet share physical resources. To achieve this goal more effectively, only the administrators of the external Hnks, gateways, and the internal resources that are made explicitly accessible should be required to take security action in response to an external connection. Owners of all other internal resources should be assured that their facilities are not accessible to outsiders. Therefore, each organization must control all exit and entry points to its internal network assuming no direct external connections are permitted without going through one of these control points. This minimizes interference with the organization's internal facilities and operations. However, this approach does impose new requirements on the functionality of gateways and the communication protocols

PAGE 21

12 used. In other words, this nondiscretionary control mechanisms in the gateway should have access to logical information about packets, such as organizational affiliation of source and destination. Finally, the costs imposed by a control scheme should be minimized. That is, per-packet processing and storage overhead in border router and end-system, additional communication during connection setup, and packet length overhead should be minimized. Other costs such as router crash should also be minimized. Classification of access controls An internetwork is composed of a number of Administrative Domains, or ADs as discussed in previous sections. It is important to distinguish between two dominant types of ADs: stub and transit. Stub ADs are interested mainly in communication with other stub ADs, that is, providing communication for their constituent endsystems. A campus network is an example of a stub AD. Transit ADs are involved in providing transit service for traffic between stub ADs. NSFNET is an example of a transit AD. Finally, there are also hybrid ADs that combine transit service with end-point communication. Considering these types of ADs, an internetwork access control scheme can be devided into two parts: stub network access control and transit network access con-, trol. Stub network access control is concerned with policy enforcement with respect to non-transit internetwork traflUc. In other words, the issue is how an AD can control both inbound (addressed to a local end-system) and outbound (sourced by a local end-system) traffic at its network boundaries. On the other hand, transit network

PAGE 22

13 access control is concerned with policy enforcement with respect to transit internetwork traffic. Controlling access to transit network resources (such as routers and links) requires additional protocol support because of the need to coordinate routing decisions among all intervening networks. These two access controls should work in harmony to achieve a dependable policy enforcement in an internetwork environment.

PAGE 23

CHAPTER 2 BACKGROUND AND LITERATURE REVIEW 2.1 Preamble The research work in this dissertation falls into three main areas of computer and communications security: internetwork access control, interdomain authentication, and secure control of internetwork transit traffic. In each of these research axeas, the problems found, the methods used, and the results achieved will be discussed in detail in a separate chapter. A thorough overview of previous research in these fields is given in this chapter. 2.2 Internetwork Access Control There have been many works on internet security. Kent and Voydock suggested some security mechanisms in high-level network protocols in their early works [6, 7]. Branstad et al. [8] and Nelson [9] have presented the development of a security architecture for secure data network system (SDNS) project within the International Standardization Organization's (ISO) Open Systems Interconnection (OSI) computer network reference model. They have developed a Security Protocol (SP4) at the ISO transport layer to provide either connectionless or connection-oriented security services. The importance of placing different security services at various layers of the OSI architecture are discussed by Ramaswamy and Fumy [10, 11]. Since Bellovin 14

PAGE 24

15 [12] pointed out some security breaches in DOD's TCP/IP protocol suite, many suggestions [13, 14, 15, 16] have been made to address internet security problems. Most of these works are on providing confidentiality and integrity of information in transit by either inserting a security sublayer or modifying existing protocol layers to utilize existing cryptographic tools. With increasing internetwork application, emerging internetworks are frequently required to connect ADs that may have competing interests. Therefore, ADs are required to control accesses to the local resources by enforcing policies at their borderline. There have been a stream of research works that focus on the resource access control in internetworked or distributed systems: • The firewall approach isolates an AD's internal networks from the outside world with special machines called firewalls. Conceptually, there are two types of firewalls: network level and application level. • The distributed systems approach provides an access control as a part of a more comprehensive security service for a certain distributed system. This often requires substantial software modification to take advantage of it since the security service is normally well integrated within the fundamental distributed services. • The packet-level authentication approach enforces access control policy on packet level. That is, border routers examine traffic flows so that only the packets with proper authenticator are allowed to exit from a local domain and to enter into a destination domain.

PAGE 25

16 2.2.1 Firewall Approach A firewall is a system or a group of systems that enforces an access control policy between two networks. The actual means whereby this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one to block traffic, and the other to permit traffic. Some firewalls place a greater emphasis on blocking traffic, while others emphasize permitting traflRc. Firewalls can be classified into two main categories: network level firewall and application level firewall. Network level firewalls generally make their decisions based on the source, destination addresses and ports in individual IP packets as in screend [17, 18] and in TAMU [19]. In general, no context is kept; decisions are made based only on the contents of the current packet. The administrator maintains a list of the acceptable machines and services and a stoplist of unacceptable machines or services. However, this approach works only if the lists are static or if the source and destination ID's carry suflScient information for access decisions. In other words, if there is a welldefined set of resources that are to be accessible by a well-defined set of entities, then the access control list could be managed manually. Alternatively, if internet addresses are structured in such a way that the gateway can classify a node according to the range into which its internet address falls, the gateway could maintain an access control list by node classes (internet address regions), and thereby achieve greater flexibility. I am interested in the more general case of a dynamic environment where network addresses by themselves do not provide sufficient information for the gateway to make

PAGE 26

17 a policy decision about whether or not to permit access; the DARPA Internet is one such environment. Internet addresses are assigned to carry topological, not logical, information [20], while policy decisions are generally based on the latter. Moreover, if the gateway relies solely on the addresses to control the access, the gateway must trust all internal nodes not to masquerade as other nodes, that is, not to fake their internet addresses. In reality, it is not hard to modify one's internet address in a decentralized environment with many personal computers and workstations. The packet level firewall cannot detect this address spoofing attack. Application level firewalls generally are hosts running proxy servers ^, which permit no traffic directly between networks [21, 22]. A proxy server is an application that mediates traffic between a protected network and the Internet. Proxies are often used instead of router-based traffic controls, to prevent traffic from passing directly between networks. Proxies must "understand" the application protocol being used and the protocol specific security should be configured (e.g., an FTP proxy might be configurable to permit incoming FTP and block outgoing FTP). Proxy servers are application specific. In order to support a new protocol via a proxy, a proxy must be developed for it. Moreover, having an application in the way in some cases may impact performance and may make the firewall less transparent. Early application level firewalls such as those built using the TIS firewall toolkit, are not particularly transparent to end users and may require some training. One popular set of proxy servers is the TIS Internet Firewall Toolkit (FWTK) which ^It is sometimes referred to as an application forwarder or a application gateway

PAGE 27

18 includes proxies for telnet, rlogin, FTP, Xwindow, HTTP/Web, and NNTP/Usenet news. SOCKS [23] is a generic proxy system that can be compiled into a client-side application to make it work through a firewall. While suitable for some situations, high-level gateways suffer from performance overhead of the gateway's high-level processing, and reduced generality and flexibility, since special high-level gateway software must be constructed for each high-level protocol supported. Thus, it would be desirable to implement access control in internet gateways without incurring the costs inherent to high-level gateways. 2.2.2 Distributed Systems Approach The Open Software Foundation's (OSF's) Distributed Computing Environment (DCE) [24] is a comprehensive, integrated set of services that supports the development, use and maintenance of distributed applications. DCE Security Service includes several components: a DCE authentication service, privilege service, registry service, authenticated RPC, and DCE access control lists. DCE authentication service was built upon the Kerberos V5 source code from MIT's Project Athena. Privilege service allows users to be identified by individual user privilege and by group membership. The user registry ensures the use of unique user names and passwords across the distributed network of systems and services, ensures the accuracy and consistency of this information at all sites, and provides security for updates and changes. It maintains a single, logical database of user account information including user and group naming information, login account information, and general system

PAGE 28

19 properties and policies. It is well integrated with Kerberos to provide an integrated, secure, reliable user account management system. The DCE security service component is well integrated within the fundamental distributed service^ and data-sharing components^ of DCE. Therefore, DCE security service alone cannot be used in internetwork environment to enforce any access control policy since it was not designed to be used stand-alone security service. In other words, DCE security service is a part of a distributed computing environment architecture that goes beyond simple communication facility and provides a wide range of computer services to applications regardless of the location of the user, the application, or the required resources. On the other hand, in many internets, such as DARPA Internet, hosts are not coupled as tightly as in distributed systems. They are just interconnected hosts in many different ADs. These host are not often interested in anything beyond using some internetwork appHcations such as FTP, e-mail, telnet, or WWW service with security. Therefore, it is not reasonable to require these hosts to change their system environment to DCE in order to use DCE security service. A less elaborate and immediate measure will be desirable to provide access control service in this environment. It would be great if an efficient access control scheme can be implemented by just modifying a protocol layer, preferably in lower layers. As mentioned earlier, DCE authentication service is based on Kerberos V5. That is, an inter-cell authentication (inter-realm authentication in Kerberos term) ^This includes remote procedure call, directory service, time service, security service, and threads service ^This includes distributed file system and diskless support

PAGE 29

20 is performed by a pairwise security sharing [25] or by a realm hierarchy [26]. This will give difficulties for hosts in DCE environment to authenticate principals in nonDCE ADs. Instead, it is not allowed to get service from those servers outside of the distributed system. It would be desirable to be able to accomplish interdomain authentications without much change in system and network environment for many ADs. Finally, DCE Security Service is based on the Client-Server paradigm. However, this is not always the case with internetworks. An effective access control scheme should work well with both client-server and peer-to-peer communications. The Secure European System for Applications in a Multi-vendor Environment (SESAME) [27] by European Computer Manufacturer's Association (ECMA) is an approach similar to DCE Security Service except for some implementation details. SESAME implementation also includes Kerberos V5 features and components as a core of the authentication service. Authentication Service extension provides support for authentication based on public key technology. SESAME shares the same characteristics as a security measure for distributed systems as DCE Security Service and is not considered appropriate to be used as an access control scheme in internetwork environments. 2.2.3 Packet-Level Authentication Approach The VISA scheme [28, 29] implements controls in a packet-forwardinggateway by working in concert with an access control server (ACS). The ACS carries out the high-level evaluation of communication requests and the gateway enforces the ACS's

PAGE 30

21 decision using the VISA scheme. That is, a gateway only allows a packet with a valid exit visa stamp to exit from and a packet with a valid entry visa stamp to enter into its network. A visa stamp is a mathematical value calculated from packet authentication keys called visa. However, this scheme requires the distribution of visas in plain text for each external session. This requires extra security measures to transport the visas to hosts requesting external sessions safely. Hence, the security of the mechanism depends largely on the protection of the visas during distribution. Moreover, VISA scheme does not specify any authentication protocol for the session initiation stage. The lack of an interdomain authentication mechanism makes this scheme less attractive in an internetwork environment with heterogeneous authentication protocols. Another packet-level access control scheme proposed by Iqbal et al. [30] formulated an approach for authenticating individual packets from a host for the duration of an external session without distributing packet authentication keys. In this scheme, a chain of pairwise authentications between neighboring principals on the path from the source to the destination host should be accomplished during the session initiation procedure. This pairwise authentication is based on the RSA public key cryptosystem to verify each other's identification. For a specific session, each pair shares a distinct mathematical value called a reference number to be used to extract a packet authentication key from the RSA private key which is shared by the pair. After the session initiation, each valid packet should contain a packet authentication

PAGE 31

22 code (PAC) which is computed from the packet authentication key using DES algorithm. This requires peer communicating entities, including network access control gateways (NACGs) in different organizations, to share their RSA private/public key pairs. This increases vulnerability tremendously since the compromise of any one gateway can make other gateways in other organizations subject to attack when they share RSA private keys. This is not desirable in today's competing and hostile internet environment. Moreover, for all but the nearby hosts, the overhead due to the consecutive pairwise authentications becomes large. 2.3 Interdomain Authentication In an internetwork environment any two principals on different machines need to authenticate each other before starting communication so that a network intruder cannot impersonate a principal to the other. There are three types of authentication in this environment: • message content authentication, verifying that the content of a received message is the same as when it was sent; • message origin authentication, verifying that the sender of a received message is the same one recorded in the sender field of a message; and • general identity authentication, verifying that a principal's identity is as claimed. Message content authentication is commonly handled by tagging a key-dependent message authentication code (MAC) onto a message before it is sent. Message integrity can be confirmed upon reception by recomputing the MAC and comparing it

PAGE 32

23 with the one attached. Message origin authentication is a subcase of general identity authentication. A successful general identity authentication usually results in a belief held by the authenticating principal (the verifier) that the authenticated principal (the claimant) possesses the claimed identity. Hence, subsequent claimant actions are attributable to the claimed identity. Authentication is achieved usually based upon cryptography and by using the authentication server that is trusted by all principals in one administrative domain. The authentication server shares a unique master key with each principal, and all the authentication information are conveyed between the server and a principal by encrypting them with the master key of the principal. To authenticate its identity, a principal must demonstrate the ability of recognizing the authentication information encrypted with his own master key, but without revealing it, to the other principal. Furthermore, distributed applications frequently require that the messages transmitted over the network be confidential only to the communicating peers, which implies at least a session key needs to be distributed first between two communicating principals before a session of confidential data transmission between them can initiate. This session key is also used to provide message origin authentication during data communication following an authentication process. That is, any message encrypted with the session key after authentication is assumed to originate from the peer principal who holds the session key. The distribution of a session key is often carried out concurrently with the authentication process.

PAGE 33

24 2.3.1 Authentication Protocols Protocols using private key encryption In 1978 Needham and Schroeder proposed the use of encryption for authentication in computer networks [31]. The proposed protocols use private key encryption as well as public key encryption. Since the principals are identified by a secret key, an authentication server is used which stores the names of the principals and the keys belonging to them. This work is the starting point for many authentication protocols that have since been developed. Denning and Sacco [32] pointed out a flaw in the private key authentication protocol proposed by Needham and Schroeder. They proposed to use timestamps to overcome the vulnerability of replay attack. But this approach has the drawback that it requires an accurate distributed clock and synchronization which is diflScult to achieve. In 1987 Needham and Schroeder again published a protocol that avoids the security deficits shown by Denning and Sacco by using nonces [33]. Their proposal requires an extra interaction between the two communicating principals but doesn't depend on synchronized clocks. Otway and Rees [34] described a protocol for efficient mutual authentication that also eliminates the weakness discovered by Denning and Sacco. Their protocol is a development of the trusted third party authentication protocols of Needham and Schroeder [31]. It requires a total of only four messages to be exchanged between the three parties involved.

PAGE 34

25 Kerberos [25, 26] is an authentication service that was built for MIT's Project Athena. Kerberos is based on the Needham and Schroeder third party authentication model [31] and uses timestamps to prevent re-use of tickets or replay. It requires a physically secure authentication server. Kerberos uses the Data Encryption Standard (DES) and is therefore not exportable. Some limitations of Kerberos version 4 [25] are pointed out by Bellovin and Merritt [35]. Kerberos version 5 [26] addressed most of these problems. Kehne et al. [36] developed a nonce-based protocol that offers the same features as Kerberos without the need of synchronized clocks. They show that their protocol uses a minimum number of messages to establish an authentication session key. Protocols using public key encrvption ITU-T Recommendation X.509 [37] proposed an authentication protocol based on public key encryption that uses a one-way handshake. The protocol needs an authentication server which stores public key certificates for those who wajit to verify the identity of a communication partner. Since the certificates cannot be forged the requirements for the authentication server are not as strong as those for authentication using private key encryption. Another approach, proposed by Woo and Lam [38], makes use of nonces in the authentication protocol. This protocol has a vulnerability to replay attack and they published a revised version [39] and showed the design steps of flawless security protocol.

PAGE 35

26 SPX [40] is an implementation of an open distributed authentication service architecture based on ISO Standard 9594-8/ITU-T X.509 Directory Public Key Certificates. Its use is intended for open network environments. It doesn't require on-line trusted components. SPX is an initial subset implementation of a larger security architecture called as Digital's Distributed Systems Security Architecture (DSSA). Assuring freshness of messages In general, all the authentication protocols for distributed systems can be divided into two categories depending upon how the freshness of key-distribution messages is determined. One category of protocols uses nonces. They exchange challenge/response messages to verify whether the response to a key distribution request is fresh or not. Since replay attacks can be effectively prevented by the use of nonces without clock synchronization, most proposed protocols in the literature are noncebased [31, 33, 34, 36, 41, 42]. The other category of protocols uses timestamps to ensure the freshness of messages. These protocols must assume that all machines are properly clock-synchronized. The number of messages required by timestamp-based protocols can be reduced since no round-trip traffic is required to guarantee message freshness as in the case of nonce-based protocols. However, due to the imperfection of clock synchronization [43], timestamp-based protocols are vulnerable to both conventional copy-and-replay and suppress-and-play attacks elaborated by Gong [44].

PAGE 36

27 2.3.2 Interdomain Authentication Protocols General identity authentication is required between a local host and the local authentication server to verify that a principal's identity is as claimed. Similar authentication is needed between a pair of principals in different administrative domains to initiate a session between them. The intradomain authentication is relatively simple and can be accomplished easily using any authentication protocol available locally such as Kerberos [26]. However, the interdomain authentication requires additional mechanisms since it is not always reasonable to assume the existence of a single trusted authentication server between any two ADs in the internet environment. As a part of Project Athena at MIT, Kerberos [25, 26, 45] is one of the most promising implementations of the authentication service. It is based on the NeedhamSchroeder protocol and uses timestamps suggested by Denning and Sacco [32] to prevent replays and to reduce messages complexity. Because of its simplicity and reliability, Kerberos has now become the most popular authentication service and adopted by a number of vendors in designing distributed systems. Kerberos is designed on a client-server model, thus it provides authentication service between a client and a server when the former tries to request a service from the latter. In fact, Kerberos places the authentication service on two kinds of servers: Kerberos server and ticket granting server (TGS). While the Kerberos server authenticates the user when he logins and issues a ticket for a TGS, it is the TGS that issues tickets for individual servers to a client. The limitations and weaknesses of the Kerberos system have been explored by Bellovin and Merritt [35], and most of

PAGE 37

28 them are due to the use of timestamps. While the initial version of Kerberos is based upon a secret-key cryptosystem, the public-key cryptosystem has been incorporated into the version 5. Kerberos provides a mechanism for supporting inter-realm authentication. The scheme requires that the Kerberos server in one realm trust the Kerberos server in the other realm to authenticate its users. Kerberos V4 [25] uses a pairwise secret sharing to perform inter-realm authentication, which has a scalability problem. That is, if there are A'^ realms, then there must be N{N -l)/2 secure key exchanges so that each Kerberos realm can interoperate with all other Kerberos realms. Kerberos V5 uses authentication forwarding and realm hierarchy to solve this problem in inter-realm authentication. Another approach suggested a hierarchical authentication [46]. That is, it suggested higher-level authentication servers that act as authentication servers for the lower-level authentication servers in different domains. The layers of authentication servers can be extended further to cover larger number of domains. However, it is not reasonable to assume that there exists always such a higher-level authentication server that can be trusted by all competing and sometimes hostile ADs. Another well-known authentication service based upon the public-key cryptosystem is SPX [40] developed by DEC. It suggested an interdomain authentication protocol and proposed a design of a proprietary certification system to provide public keys to the principals.

PAGE 38

29 2.3.3 Formal Protocol Analysis and Evaluation Most authentication protocols found in the literature are described only by listing the messages sent between principals and by explaining what results will be achieved after each step of message transmission, in quite an informal and imprecise way. To formalize the definition of a protocol, Burrows, Abadi, and Needham defined a logic of authentication [42, 47] (hereafter called BAN Logic) to describe the initial assumptions upon which a protocol is based and the meaning of each message in a logical and precise way, and to express exactly what final beliefs can be obtained by communicating principals after the completion of a protocol run. They demonstrated the strength of BAN Logic by applying the logic to a number of authentication protocols and evaluating the nature of the guarantees those protocols offer. In their well-known paper introducing BAN Logic, the formalized goals of authentication were explicitly stated, and the protocols which cannot achieve these goals were appropriately criticized and improved wherever possible. 2.4 Secure Control of Transit Internetwork Traffic Network access control methods that restrict the information flow between endsystems on stub domains have been discussed in previous sections. However, controlling access to transit network resources (such as routers and links) require additional protocol support because of the need to coordinate routing decisions among all intervening networks. Organizations cannot simply enforce policy restrictions on a unilateral basis at packet forwarding time. Internetwork routing decisions must be

PAGE 39

30 made according to policyrelated parameters such as access rights and cost, in addition to the traditional parameters of connectivity and delay [48, 49]. Consequently, policies pertaining to network resources must either be implicit in the topology of an internetwork, or advertised to the anticipated resource users. Only then can entities throughout the internetwork determine the logical, policy-based connectivity of an internetwork and compute valid routes. 2.4.1 Issues in Internetwork Environments This section defines some of terminology and assumptions regarding internetwork environments in order to provide appropriate background for the subsequent discussion. Internetwork topology Some routing protocols such as Exterior Gateway Protocols (EGP) [50] place restrictions on internet scale and topology. However, any inter-AD routing protocol should have the potential of supporting very large scale internetworking. In an internet of enormous size such as DARPA Internet it would be unwise to design a protocol that relied on topological restrictions; enforcement would be almost impossible. Consequently, one of the design goals should be allowing maximum degree of flexibility in regard to the configuration of the internetwork. A traditional network hierarchy includes long haul, regional and campus (stub) networks. However, there are exceptions to the hierarchy in the form of lateral (bypass) links. These exceptions to the otherwise regular topology are not dispensable and must be supported, perhaps at the expense of optimality.

PAGE 40

31 Protection of network resources Many discussions of network security are actually discussions of end-system protection in a network environment [6, 51, 52, 53]. One of our assumptions in the design of transit network controls is that both stub and transit ADs have valuable network resources that are themselves the subject of policy [54]. From this perspective, it is imperative to eiddress the protection of network resource in addition to end-system protection. If control is left to the end-systems, valuable stub-AD network resources may be consumed by unauthorized traffic. Rejecting packets at the end-system is too late from the perspective of network resource usage. Moreover, unrestricted network access increases the vulnerability of ADs to denial of service attacks in the form of packet storms. Finally, some ADs might need to control which routes are used to and from their internal end-systems due to cost or security reasons. Because routing is a network level function, these controls must also involve network level entities and can not be left to transport session end-points [54]. 2.4.2 Policies We can find an analogy between ADs and sovereign countries, each with a specific set of foreign policy statements regarding interaction with foreign entities (other ADs). For example, a country may have policies restricting foreign visitors to specific areas or restricting travel privileges of the local populace when visiting foreign countries. Countries may also have specific policies pertaining to transit travelers, such as restricting entry on the basis of the traveler's itinerary. Security

PAGE 41

32 policies regarding international travel can express policy as to passport and visa requirements, length of stay, etc. Accounting or billing policies may concern, for example, visa fees or departure taxes. ADs can express similar policies regarding communication with external entities, such as restricting internal systems available for external access or restricting external systems available for internal access. Transit traffic may or may not be allowed, or it may be restricted to specific source and/or destination ADs or end-systems. Policies can also embody security requirements, such as authentication and authorization for inter-AD traffic, as well as accounting and billing conditions [55]. Network level policies are primarily concerned with unauthorized access to network resources, denial of service, and inappropriate accrual of communication-related charges. These threats can all come about through attacks on the authenticity and the integrity of internetwork packet traffic. Some concerns are of greater importance to stub networks and others, to transit networks. Stub and transit policies Due largely to the nature of service provided, stub and transit ADs tend to express different policies. Policies expressed by stub ADs, for the most part, serve to protect internal resources from external access, while those expressed by transit ADs tend to be cost-related. Another way of making this distinction is to observe that transit ADs, by virtue of providing transit service, are inherently more open than their stub counterparts. Furthermore, subversion of transit AD's policies will, in the worst case, result in denial of service, whereas subversion of stub network polices can

PAGE 42

33 potentially disrupt the end-systems themselves. Another reason for separating the respective policies is the difference in accounting and billing requirements. Stub ADs are more likely to bundle communication costs into billing for end services, if any such billing occurs. Transit ADs are more likely to charge for the communication itself. Finally, stub AD policies include route selection criteria, which dictate how the AD's packets travel to their destinations. In some respects, the requirements for transit policy enforcement are simpler than those for stub policy enforcement. However, several factors complicate the implementation of the latter. First, in an internetwork, a packet may travel through a number of transit ADs on its way to the destination. Consequently, applicable policies from all transit ADs must be considered when a packet is being sent; whereas for control of stub resources, only the policies of the two end-point ADs need to be taken into account. In addition, transit control has to be reconciled with topology changes (routers or links going down). If in the middle of a connection any component of the route becomes disabled, an entirely different policy may come into effect. Also, when a transit AD decides to account and/or bill for resource usage, coordination is required to pass charges back to the end points. Moreover, stub route selection criteria must be integrated with transit control policies to determine the appropriate routes. These factors add to the complexity of potential enforcement mechanisms. Based in part on the difference in policies, and in part on the functionality required in any routing (i.e., transit) mechanism, transit and stub AD mechanisms also differ. By analogy with international travel, in most countries transit travelers are

PAGE 43

34 set apairt from other visitors. They are issued special transit visas and are restricted in movement and length of stay. I discuss transit mechanisms further in later sections. Policy attributes Network usage policies can be based upon a number of attributes: • Endpoint policies place restrictions on the source and/or destination of traffic. • Path policies place restrictions on other ADs of the path in addition to the source and destination ADs. • Security attributes express requirements for authentication, data integrity, replay detection and privacy. • Temporal parameters include restrictions on usage based on time of day, day of the week or other timerelated parameters. • Quality of Service policies discriminate according to the service parameters (e.g., delay, throughput) made available to different users. • Accounting/Billing policies express conditions related to charging and accounting. A typical policy statement can be based upon several policy attributes. For example, the policy statement, "transit voice traffic from ADa is accepted between 2 and 6 a.m. with a per packet charge", applies to transit traffic and combines application protocol, temporal and accounting/billing attributes. Further examples of policy types can be found in RFC 11 25 [55].

PAGE 44

35 2.4.3 Controlling Transit Internetwork Traffic There are two basic approaches to controlling transit traffic. In the first part of this section, an approach based on the extension of stub network access control mechanisms is discussed and its limitations are identified. Subsequently, the alternative approaches based on integrating controls into internetwork routing are considered. Extending stub network access controls One potential method of enforcing transit policy enforcement is to extend existing stub network access control mechanisms to the generalized internetwork model. Visa protocols [29] were developed originally to provide datagram-level control at AD boundaries. The process of establishing authorization in Visa-controlled transit ADs is essentially the same as for stub ADs in the Visa protocol. The major difference is that the source host must obtain a transit visa for each transit AD that requires one, in addition to obtaining a pair of exit/entry visas from ADsrc and ADdst. In the worst case, each transit AD's ACS will conduct an authorization and authentication procedure before issuing a transit visa, and each packet will have to carry a separate visa for each intervening AD. Of course, transit ADs may choose to issue visas automatically, or not require any visas at all where transit traffic is concerned. Furthermore, ADs could program their ACSs to obtain and issue transit visa-keys in advance of the actual communication. This would reduce the setup delay at connection establishment time. On the other hand, such mechanisms increase the problems associated with visas expiring before, or while they are in use.

PAGE 45

36 Although the extension of the Visa concept to transit control is rather straightforward, the approach does not scale well to an internetwork where many ADs, both stub and transit, want to control traffic flows. For example, visa acquisition and route setup must be repeated (or adapted) each time an involved visa-router goes down. Moreover, a source AD has no way of determining if it will be issued a visa without incurring the overhead of contacting the particular ACS in question. The essence of the problem is that transit control is related to packet routing. Therefore, controls for transit should be incorporated into the route calculation itself, not only into the packet forwarding function. The access control policy in SP3 [56] is also endpoint-oriented. It is concerned mainly with determining whether or not two peers may communicate and what type of information they may exchange. This and other network access control schemes such as router packet filters [17] face the same limitation when it comes to controlling transit traffic. That is, these schemes enforce controls on packet forwarding and do not provide information to the route computation. In summary. Visa protocols and other network access control mechanisms are best suited for stub network control. Transit network control for large internetworks is more efficiently achieved by integrating policy considerations into the route computation process. Policv routing As described earlier, the central goal of transit traffic control is to allow ADs to express and enforce policies regarding transit traffic. Our discussion in the previous

PAGE 46

37 section demonstrates that transit control is intimately related to Inter-AD Routing. An interdomain routing that incorporates policy constraints is called policy routing (PR). In this section two approaches of policy routing are summarized. The first is the Border Gateway Protocol (BGP) [57, 58, 59] which is intended to support a limited notion of policy. The second is the Inter-Domain Policy Routing (IDPR) proposal designed to support more general policies [48, 49]. Policy routing operates at the network layer. In both example architectures, only border routers and associated interdomain route servers are directly affected by the presence of the interdomain routing protocols. End-systems and interior routers can continue employing whatever internetworking protocols are desired within their particular ADs. Border routers operate on behalf of the end-systems. For this reason, the term source hereafter refers to the border router in the AD of the source endsystem. Border Gateway Protocol . BGP is an external gateway protocol for communication between routers in different ADs. BGP is a replacement for the older EGP [50] that was used on the ARPANET. BGP was first proposed in 1989 [49] and Version 3 [58] and Version 4 [57] have been developed so far. Its foremost goal is to provide efficient and robust interAD routing with rapid convergence and loop detection for arbitrary internetwork topologies. In addition, it provides policy-based distribution of routing information. It is aimed mainly at transit ADs and can interoperate with other routing protocols.

PAGE 47

38 BGP is designed under the following assumptions: 1. Policies can he expressed using information about the full AD path that packets will travel to a destination. 2. Transit policies apply uniformly to all endpoints. BGP uses hop-by-hop routing and a distance vector algorithm for the next hop selection. One common benefit of traditional distance vector algorithms is the ability to hide network structure. Neighboring nodes exchange reachability information for a specific destination in the form of distance metrics corresponding to each next hop. Nodes do not exchange information about subsequent hops to the destination. BGP augments this traditional approach by distributing full AD-level paths. In other words, for each destination advertised, nodes specify the AD-level path to that destination. As a result, BGP provides less information hiding in return for the ability to detect routing loops quickly. By using the full AD path to detect loops BGP avoids imposing topological restrictions on AD interconnection (such as those imposed by EGP). In addition, AD path information can be used as a policy criterion for route selection. BGP allows for limited policy-based route selection. Each AD's BGP router can select its next hop based on the information provided in the full AD path, in addition to the distance metric. For example, AD a can reject all routes through ADbOn the other hand, each AD must apply the same route selection decision to all packet sources, including itself. For example, ADa cannot reject all routes through ADb for itself without affecting its neighbors, and vice versa. Similarly, an AD can not apply

PAGE 48

39 one policy to one neighbor and a second policy to another neighbor. Since BGP was not intended to implement policies that discriminate between traffic end-points with arbitrary granularity, the approach achieves its goals [60]. Each BGP router can be configured according to its AD's local policy. Even though local policy is not distributed among ADs, it is represented in a universal policy language. A policy in this language is an expression: [Network — list, AD — path] = preference The semantics of a policy are as follows: if a routing update for a network in the Network-list is received via the AD-path and its preference metric is higher than that of a path currently in use, then, this update must be redistributed to all ADs. Inter-Domain Policy Routing . An alternative architecture for policy routing has been developed to support a wider range of policies; the Inter-Domain Policy Routing (IDPR) proposal allows stub and transit ADs to express and exchange packet routing and forwarding policies. The most distinguishing feature of this approach is the use of AD-level source routing. It uses a Link State algorithm ^ to compute source Policy Routes (PRs) at the granularity of ADs. Each AD expresses its policies in a standard form, called Policy Terms (PTs) [49], and distributes them to other ADs. Each AD ''In a link-state protocol a router does not exchange distances with its neighbors. Instead each router actively tests the status of its link to each of its neighbors, sends this information to its other neighbors, which then propagate it throughout the AD. Each router takes this link-state information and builds a complete routing table. Practically, link-state protocol will always converge faster than a distancevector protocol.

PAGE 49

40 designates special Route Servers (RSs) to collect PTs and compute policy routes for constituent users. The basic assumptions of this model are: 1. Most policies can be clajssified and expressed in a standard notation. 2. Policies and inter-AD connectivity change relatively slowly. 3. End-point specific policies should be supported. Two primary concepts in this proposal are Policy Routes (PRs) and Policy Terms (PTs). A PR is a series of ADs. It is essentially an AD-level source route. In other words, there may be multiple physical realizations of a PR given multiple physical connections between ADs and multiple intra-AD routes. The actual selection of a particular physical path is done at packer forwarding time by each intervening AD rather than by the source AD at route computation or route selection time. This lazy evaluation provides for a more adaptive protocol and unrestricted AD interconnection. Policy Terms (PTs) are the units of routing information exchanged by communicating ADs. Each PT represents a distinct policy of the AD that expressed it. Policies are expressed by source, destination, and transit ADs. The source AD may select all transit ADs while transit and destination ADs control which source and destination ADs can communicate via which directly connected ADs. ADs run link state routing algorithms to compute their respective tables of PRs. There may be multiple PRs listed for the same destination AD, each with a different set of conditions associated with its use (e.g., quality of service, time-of-day, or user class).

PAGE 50

41 Note that ADs (with the exception of the source AD) do not exert control over the entire Policy Route. Referring back to our travel analogy, it is difficult to enforce policies that are based on information that is not verifiable at the point of reference. For example, it is difficult to enforce a policy that dictates non-admittance to anyone who has ever passed through country X, since it is very much dependent on X stamping passports reliably. In the environment of interconnected ADs, a transit AD can verify the previous and next hops because of its direct connections and the feasibility of employing pairwise authentication with the relatively small number of neighbors. Verifying other transit components of the PR is difficult, if not impossible. Each AD has one or more Route Server (RS), an entity that collects Policy Routing information from other ADs, distributes local policy information to other ADs and computes, as well as issues, PRs to local end-systems. Actual policy enforcement is done at a Policy Gateway (PG) which, in addition to the usual task of forwarding packets, handles validation and verification of the PRs attached to the incoming packets. A path is established with the first packet carrying the full PR, that is, the complete sequence of ADs in the route and applicable PT identifiers. PGs along the way make sure that the PR agrees with the local PTs (through use of templates, for example). The result is cached so that a specified PR handle can be used in the future to refer to the cached entry. Successive packets carry a PR handle, not a full PR. Many transport level sessions, and even host-pairs, may share a single PR if the policies enabling it are not end-system-specific; this reduces the average

PAGE 51

42 latency and router state overhead associated with interdomain communication. PGs use these handles in the packets to check for cache entries. PGs also may relate return flow packets with forward flow. Given information about the next AD for a particular packet, each PG selects the next PG based on the information exchanged in a traditional routing protocol. Comparison of approches Policy routing allows ADs to interconnect to the global internet while still protecting network resources from general, unconstrained use. However, policy routing mechanisms do not preclude the need for network access controls in the border routers of ADs that wish to control access to individual end-systems. One essential difference between Visa and the policy routing approach is the per session setup overhead. Transit Visa requires that a dialog transpire between the source and each transitVisa network's ACS, and that corresponding key be distributed. Consequently, the initial setup delay grows in proportion to the number of transit networks. For short transactions such overhead is not acceptable. A PR-based approach such as that in BGP or IDPR avoids this setup dialog through background distribution of policy term information that is used in route computation. The work that the Policy Routing protocols do to distribute policy terms and compute authorized routes must be done at the time of the session setup in Visa. In particular, with Visa protocol this translates into a reject packet, ACS dialog, and visa-key grant message for each AD in the path. Moreover, this assumes that the source attempts communication over a path for which it has authorization. If there is a

PAGE 52

43 conflict with even one transit AD's policy, the process must begin again. Policy Routing incorporates policy into the route computation process in advance of the actual communication, thereby avoids this problem. On the other hand, the PR schemes, as described thus far, rely on post-facto detection of abuse and in that sense, are less secure than network access controls schemes such as Visa protocols. In chapter 5, 1 address the integration of preventative mechanisms into policy routing to achieve secure control of transit traflSc.

PAGE 53

CHAPTER 3 PACKET-LEVEL ACCESS SECURITY SCHEME 3.1 Motivation With increasing internetwork applications, emerging internetworks are frequently required to connect administrative domains (ADs) that may have competing interests. In this environment, security threats of unauthorized accesses to the resources axe very high. Therefore, an efficient and effective access control scheme is needed. However, most work on internetwork security aims to provide confidentiality and integrity of information in transit by either inserting a security sublayer or modifying existing protocol layers to utilize existing cryptographic tools [7, 8, 14, 16]. Although firewalls protect internal resources from unauthorized accesses from outside, this can only be achieved at the expense of inflexibility and inconveniences for the internal users. On the other hand. Security Services of OSF's DCE [24] and ECMA's SESAME [27] are rather complex and exclusive solutions for client/server-based distributed systems and not for immediate use in the internetwork environment. More specifically targeted work towards internetworks [28, 30] are suffer from security vulnerability and excessive overhead. This led us to develop a more efficient and effective stub-domain mechanism, a packet-level access security scheme (PASS) [61]. PASS requires each organization 44

PAGE 54

45 to control all the exit and the entry points of its internal network to implement a nondiscretionary access control mechanism to isolate pure-internal resources from externally accessible resources. PASS does not require each AD to have dedicated local access control servers. This makes PASS scheme more acceptable in many situations. Moreover, PASS is efficient in the sense that the protocol overhead is low enough so as not to affect the configuration of existing higher-layer protocols and applications. The primary goal of PASS is to allow an AD to control communication between its constituent end-systems and end-systems in other ADs to a specific system level. This goal can be achieved if the end-systems involved can be trusted. This trust can only be verified and maintained by strictly controlling the exit and entry of the packets to an AD since the only information available about a packet is attached to the packet in a datagram network. In other words, a packet can only leave the source AD if • the source end-system has been authorized to communicate with the corresponding destination end-system, • the packet is originated at the source end-system within a reasonable time interval, • the packet is properly addressed for the destination end-system, and • the packet has not been modified in transit.

PAGE 55

46 Similarly, a packet can only enter the destination AD if the conditions similar to those mentioned above are met. 3.2 Network Environment I assume that the internetwork closely follows the model of the DARPA Internet, which is substantially similar to the Open Systems Interconnection (OSI) model. The essential features of the environment are as follows: • End-systems are autonomous and cannot necessarily be trusted. • ADs are interconnected with routers; between any pair of end-systems in different ADs there are at least two routers, one belonging to each of the ADs. The terms border router and interdomain router are equivalent. • All information flows via datagram packets. A packet consists of a header that includes addressing and other control information, and a data segment that is not intelligible to routers. • A packet may flow through several untrusted ADs on its way to the destination. • Both source and destination end-system addresses can be forged. It is not possible (using hardware methods) to determine reliably which end-system actually sent a packet or to prevent a packet from being seen by an unauthorized end-system. • Packets traveling across an internetwork may be lost, duplicated, or re-ordered.

PAGE 56

47 • Successive packets between a given end-system pair may travel along different routes. In addition to these, there must exist a global name service which, in a secure and reliable fashion, provides a mapping from end-system network addresses to AD identifiers in addition to the rather traditional mapping between end-system names and addresses. ITU-T X.509 [37] will provide this service along with the public key certificates of principals involved. 3.3 Components of PASS To achieve the goal of this scheme, several components of PASS should work together in concert on a given internetwork environment. The following components of PASS are described in this section: internet access control gateway, passes, endsystems, and certification authority (CA). 3.3.1 Internet Access Control Gateways An internet access control gateway (lACG) is a border router that uses the PASS protocol to enforce access controls. All interdomain connections must be implemented via PASS-routers. Unlike other border routers, lACG is also responsible for authorization and authentication with end-systems in its local AD. lACGs are trusted and assumed to defend against attempted abuse from external entities. This assumption is critical since these gateways issue and maintain packet authentication keys.

PAGE 57

48 The choice of the authorization and authentication procedures used by an lACG is the decision of each individual AD. The procedure may involve establishing a highlevel conversation with the end-system, in which a password, biographical data, or other authenticating information is requested. The public key based authentication protocol which is used in interdomain authentication can also be used in this intradomain case. Access control decisions may be most appropriately made according to group or class affiliation and associated category sets that determine access rights. The PASS scheme itself does not dictate or constrain any particular authorization scheme. Regardless of the approaches used, the PASS scheme assumes only that a yes/no decision is passed to the PASS software. This dissertation describes the PASS interface to lACG, not the lACG design itself. Finally, significant application-specific access control is left to the end-systems and applications; our scheme addresses only control of access to the hosts on a network. The functions of an lACG can be summarized as follows: • On receipt of an AUTH-REQUEST packet from a local end system, an lACG authorizes and authenticates the host. • Performs interdomain authentication with a peer lACG during the pass request procedure on behalf of an end-system in its local AD. i • Issues a new pass to the peer gateway. • Forwards a new pass which is granted by the peer gateway to the initiating local host. i

PAGE 58

49 • Expires a pass upon termination request by participant host or gateway, or upon timeout, and notifies all parties involved hosts and other gateways. • Traps all packets and searches for a pass in pass list with source, destination addresses and pass identifier. • Computes pass with the pass-key found and compares it with the one attached to the packet. • Rejects a packet without a valid pass. • Forwards packets bearing a valid pass through. • Accepts a PASS-GRANT packet from the remote lACG and adds a new pass entry to the pass list. • Issues a REVOKE packet and deletes a pass entry from the pass list. • Upon pass expiration, it informs the peer lACG of the fact. Figure 3.1 shows a simplified state diagram for an lACG at a session initiating domain. 3.3.2 Pass Key A pass key is an unique value assigned to a communication session between a pair of end-systems on different ADs. Depending on the signature method, it may be an encryption key (with DES) or a secret prefix/suflBx (with MD5 [62]). It is used to compute a packet signature, called here as a pass, for the traflSc from a source to a destination end-system. Each packet that belongs to an authorized session carries

PAGE 59

so I Figure 3.1. A simplified state diagram for a source lACG a distinct pass value in the IP header option field^ [63] that is a function of pass key and the packet contents. In most types of communication, packets will flow in both directions, so both end-systems are both a source and a destination at the same time. Therefore, there are two possibilities of key assignment: one-way pass-key and two-way pass-key. A distinct pass-key can be assigned to each direction of communication after two separate one-way authentications. To reduce the protocol overhead, an AD can allow its lACG to issue a two-way pass key automatically after a mutual authentication. With current implementation, each direction of a session is assigned a unique pass key after a successful mutual authentication. This increases the level of security since each destination lACG issues a pass-key for the inbound traffic after successful ^Or in the Authentication Header with IPv6

PAGE 60

51 authorization of the source party. This scheme can be easily modified to assign a twoway pass key to a session for simplicity. This requires an additional authorization for the other direction of traffic. Each host that makes use of the internetwork communication maintains an active pass list. Each entry in the pass list consists of a pass, pass identifier to differentiate multiple sessions between the same host pair, and the addresses of the machines involved in the session, and any restrictions that may apply such as pass lifetime. lACGs also maintain a pass list to enforce access control on the traffic flowing through them. 3.3.3 PASS End-Svstems End-systems using PASS protocol to communicate each other are called PASS end-systems. Any PASS end-system who wants to communicate with end-systems outside of its AD must obtain a pass-key allowing its packets to exit from the local AD and enter to the destination AD. In order to obtain exit authorization it needs to contact one of the local lACGs which authenticates its identity and authorizes its access rights. The local lACG then contacts the peer lACG in the destination AD to request a pass-key for its local end-system. After successful authorization and authentication, the remote lACG grants a pass-key to the local lACG, which in turn forwards it to the source end-system. Thereafter, a pass (computed with the corresponding pass-key) must be attached to every packet sent from the requesting end-system to the apparent destination. To

PAGE 61

52 do this, an end-system should have a proper means for generating pass and a secure storage for active pass list. An end-system does not have to have knowledge of the local lACG's address; this may instead be supplied by the lACG when an end-system first attempt to communicate across the AD boundary without a proper pass. An end-system can use an authentication scheme available locally or can be authenticated by an lACG during session initiation phase of the PASS protocol. 3.3.4 Certification Authorities In the X.509 directory-authentication framework, a certification authority (CA) is an authority trusted by one or more users to create and provide public-key certificates for them. The heart of the X.509 scheme, which is used during interdomain authentication, is the public-key certificate associated with each user. These user certificates are assumed to be created by some trusted certification authority (CA) and placed in the directory by the CA or by the user. The directory server itself is not responsible for the creation of public keys or for the certification function; it merely provides an easily accessible location for users to obtain certificates. The public-key certificate includes the following elements: • Version: differentiates among successive versions of the certificate format; the default is 1988. • Serial number, an integer value, unique within the issuing CA, which is unambiguously associated with this certificate.

PAGE 62

53 • Algorithm identifier, the algorithm used to sign the certificate, together with any associated parameters. • Issuer, the CA that created and signed this certificate. • Period of validity, consisting of two dates: the first and last on which the certificate valid. • Subject: the user to whom this certificate refers. • Public-key information: the public key of the subject, plus an identifier of the algorithm for which this key is to be used. • Signature: covers aJl of the other fields of the certificate, and consists of a hash code of the other fields, encrypted with the CA's private key. The CA signs the certificate with its secret key. If the corresponding public key is known to a user, then that user can verify that a certificate signed by the CA is valid. User certificates generated by a CA have the following characteristics: • Any user with access to the public key of the CA can recover the user public key that was certified • No party other than the certification authority can modify the certificate without this being detected If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates can be placed in the directory for access by all users. In addition,

PAGE 63

54 a user can transmit his or her certificate directly to other users. In either case, once a principal A is in possession of the other principal B's certificate, B has confidence that messages it encrypts with A's public key will be secure from eavesdropping and that messages signed with A's private key are unforgeable. If there is a large community of users, it may not be practical for all users to subscribe to the same CA because it is the CA that signs certificates, each participating user must have a copy of the CA's own public key in order to verify signatures. This public key must be provided to each user in an absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical for there to be a number of CAs, each of which securely provides its public key to some fraction of the users. An example of CA hierarchy is described in detail later. 3.4 Protocol Description PASS protocol consists of three phases. In the session initiation phase, an endsystem first obtains authorization for transferring packets to a destination end-system outside of its own AD. If successful, the local lACG requests pass-key to the lACG in the destination AD and acquires it. In the packet forwarding phase, the pass key is used to generate a packet data signature that is attached to all packets belonging to the authorized session. Finally, the session revocation involves the termination of a pass either because of normal expiration or by explicit revocation. In the remainder of this section, each protocol phase is discussed in detail.

PAGE 64

55 Figure 3.2. An illustration of two communicating PASS ADs In this protocol, I assume a one-way communication, that is, an one-way transfer of packets from a source end-system to a destination end-system. Therefore, only one-way authentication is sufficient to do this. A different pass-key should be assigned to the other direction of a communication through the same steps of the protocol. However, this protocol can be extended for two-way communications by just using a mutual authentication and a two-way pass-key. Figure 3.2 illustrates two participating ADs which communicate using PASS protocol, where Ha is the source end-system and Hb is the corresponding destination. 3.4.1 Notation The following notation is used throughout the description of the protocol: • PassKij denotes a pass-key shared by a source end-system Hi and a destination end-system Hj. • KUi, KRi denote public and private keys of principal i. • EiclData], DK[Data] denote encryption and decryption, respectively, of Data with key K.

PAGE 65

56 • EKRi[Data], DKUi[Data] denote signing and verification, respectively, of Data using a public key system. • Fhaah{Data) is a hash value of one-way hash function applied to Data. 3.4.2 Session Initiation Phase Each interdomain communication between PASS end-systems requires a session initiation procedure which does the following: • Authorization and authentication of two communicating end-systems by each of their local lACGs. • Issuance of a pass-key as a result of successful authorization and authentication. • Distribution of the pass-key to all parties involved. Exit authorization The protocol is put in motion when an end-system, Ha-, in ADa begins communication with another end-system, Hb-, in ADi,. Ha may already know that its intended destination is in a different AD, either because it has previously communicated with Hb or it may have discovered this through some external mechanism (e.g., a name server). In this case. Ha may communicate directly with an lACG in its AD, lACGa, by sending an AUTH-REQUEST packet. Otherwise, since the packet carries no pass, the exit lACG will reply with a REJECT packet which notifies Ha that the intended destination is non-local, and that it must acquire a pass by first getting authorization and authentication from a local lACG. Therefore, these first two packets can be saved if Ha knows that its intended destination, Hb, is in a different AD beforehand.

PAGE 66

57 DATA Ha^IACGa-. [Ha, Hb, Data] (3.1) REJECT lACGa^Ha i [Ha,Hb,IACGa] (3.2) Ha then sends an authorization/authentication request packet, referred here as AUTH-REQUEST packet, to lACGaAUTH-REQUEST Ha-^IACGa'. [Ha,EKR„J^Hb,TS„^]] (3.3) This message is intended to establish the identity of Ha and the authenticity and the integrity of the message. This is done by signing the packet with the private key of HaIf conventional encryption is used, the signing would be done with the secret key shared by Ha and lACGaAUTH-REQUEST packet also claims that the message was intended for Hb. On the other hand, the timestamp, TSjja guarantees the freshness of the message. lACGa now needs i^o's public key to extract the contents of the signed packet. It is often the case that lACGa has the public key of Ha in its local storage for faster processing. Otherwise, lACGa should obtain the public key certificate which contains the public key of Ha from X.509 directory. With the successful extraction of packet contents, lACGa checks TSnaOtherwise (i.e., the packet has been modified during transmission), lACGa either discards

PAGE 67

58 the packet or sends a REJECT packet to Ha notifying it of the fact. lACGa does similar things when TSna ^^^^ 1°°^ normal to prevent replay attacks [64]. Next, lACGa has to authorize communication between Ha and Hf,. This step is dependent on the particular policy employed by ADa. For example, it may involve a higher-level authentication dialog between lACGa and HaThe details of this procedure are beyond the scope of this paper. If the authorization fails, I ACQ a notifies Ha that it is not allowed to communicate with Hb. Otherwise, lACGa proceeds to finish up the authentication either by following the local authentication protocol available or by verifying the AUTHREQUEST packet using the public key of Ha. Upon successful authentication, lACGa sends PASS-REQUEST packet to the destination AD, ADbThis request should be delivered to the counterpart lACG, lACGblACGa may know the address of lACGb from the previous communication in which case PASS-REQUEST may be sent directly. It could also obtain lACGbS address via a name service query [65]. Otherwise, PASSREQUEST packet is addressed to the destination end-system, Hb, and eventually it is picked up by lACGb since it does not have proper pass on it. PASS-REQUEST lACGa^Hbi [IACGa,EKR:^cGa[Ha,Hb,TSa]] (3.4) Again, this packet is signed with lACGa^s private key to provide proof of authenticity and integrity of the message. Timestamp TSa guarantees the timeliness and should be unique since it is used as a pass identifier later.

PAGE 68

59 Entry authorization When a PASS-REQUEST reaches ADb, it is trapped by lACGb since it does not have proper pass on it. lACGb first verifies that Hb indicated in the PASS-REQUEST is in fact an end-system in its AD. This is necessary in order to minimize time spent on potentially malformed PASS-REQUESTs. Next, lACGb authorizes communication between Ha and HbWhen it fails, the REJECT packet will be sent to lACGa. Otherwise it proceeds to the authentication procedure. In order to authenticate its contents by recomputing the signature, lACGb needs the public key of lACGaThis public key is found in the public key certificate of lACGa which is obtained from the X.509 directory as a response to the request of lACGbIn the mean time, lACGa requests the public key certificate of lACGb to a local X.509 Certification Authority (CA), CAa, to get the public key of lACGbBoth lACGs may look up local storage to find the other lACG's public key used in previous communications. Using the public key of lACGai KUjACGai lACGb recomputes the signature of the PASS-REQUEST and verify both its origin and data integrity. Both freshness and uniqueness of the PASS-REQUEST packet are inferred from the enclosed timestamp, TSa [43, 66]. Pass grant and distribution After successful authentication, lACGb issues a new pass key in the following form:

PAGE 69

60 PASS-GRANT : lACGb ^ lACGa : EKRj^cadHa. ^6, Alg, LT, EKUj^.^AEKRj^cadTSa, PassKab]]] (3.5) A PASSGRANT packet includes the source and destination end-system addresses, Ha and Hi,, respectively, that are authorized to use this pass. In other words, this states that the pass key has been issued by Hb and is being used for the packets destined for Hb from HaPASS routers lACGa and lACGb use these endsystem addresses to locate the appropriate pass-key when they associate incoming packets with a particular communication session. The timestamp TSa is used here as an identifier of the pass key which is assigned to a pair of end-systems. Ha and Hb. This value should be unique and unused before. In that sense, it is used here as a nonce [67]. LT is the lifetime of a pass-key to be used to expire the pass-key when the given condition is met. A pass-key can be made obsolete at a specific system time or after some specific amount of time elapsed. A maximum number of packets transmitted or a maximum amount of data transferred can also be used as a LT. PassKab is a pass-key granted by lACGb to be used to compute packet signatures for the traffic destined for Hb from HaDepending on the signature method, which is specified in Alg field, PassKab may be either a secret key of an encryption system such as DES or a secret prefix/suffix for a message digest scheme such as MD4 or MD5.

PAGE 70

61 To achieve the confidentiality of the pass-key during distribution, it is encrypted with lACGaS public key, which allows only lACGa to decrypt it. Note that the passkey is signed by lACGb before it is encrypted. This is to guarantee the integrity and authenticity of the key and prevent the possible modification or fabrication attack [68]. When lACGa receives a PASS-GRANT packet, it first verifies that Ha, Hb and TSa are indeed the same values that were sent in the PASS-REQUEST packet. It then verifies the PASS-REQUEST packet with the public key of lACGb, KUiacg^Finally, it decrypts and stores the pass-key. Next, lACGa may reply with ACK packet which notifies lACGb that the PASSGRANT packet has arrived safely and it successfully has decrypted PassKabACK lACGa^IACGb-. [IACGa,Epa,,KjIACGb,TSa]] (3.6) ACK packet may be skipped for brevity even though it makes the interdomain authentication more complete. In the meantime, both lACGa and lACGb create a new entry in their pass-table and lACGa forwards the pass-key to Ha by sending PASS-FORWARD packet. PASS-FORWARD : lACGa ^ Ha : [lACGa, EKR.^caAHa, Hb, TSa, Alg, LT, EKu^^[EKR,^^aa[TSH., PassKabMS.l)

PAGE 71

62 This packet is signed with lACGaS private key in order to be verified by Ha with lACGaS public key. The pass-key is encrypted with HaS public key. This prevents any other principal in the network from decrypting and acquiring the pass-key. 3.4.3 Packet Forwarding Phase When the setup phase is completed, Ha can begin communication. Each packet that Ha sends to Hb has to be accompanied by a pass. Since there are possibilities that more than one communication sessions are outstanding between Ha and Hi,, a pass identifier should be included in those packets. In this scheme, TSa is used for this purpose. With it, the PASS routers can successfully identify an entry in their pass table. A pass is computed as: PASS = Fhash{[Header, Data], PassKab) where, Fhash is the signature function determined by the Alg field agreed on during the session initiation phase. The resulting data packet has the following form which is also shown in Figure 3.3 with IP version 4: DATA-PACKET Ha ^ H^ : [Header, PassID, Pass, Data] (3.8)

PAGE 72

63 IS 16 VERSION HEADER LENGTH TYPE OF SERVICE IDENTinCATION TIME TO LIVE PROTOCOL TOTAL LENGTH FLAGS FRAGMENT OFFSET HEADER CHECKSUM SOURCE IP ADDRESS DESTINATION IP ADDRESS PASS IDENTIHER PASS DATA Figure 3.3. IP Version 4 PASS data packet format Exiting source AD When a packet with a pass arrives at lACGa-, it has to be checked to show authorization to leave its local AD, ADa^ as well as authenticity of its contents. lACGa first looks up its peiss-table with the source, destination addresses and passkey identifier supplied by the packet. Successful look-up indicates the existence of exit authorization by lACGaNext, I ACQ a verifies the packet signature by re-computing the packet signature and comparing it to the pass attached to the packet. If the two values match, lACGa can safely conclude that packet contents are authentic. The packet is now forwarded to the destination AD through the internetwork.

PAGE 73

64 Entering destination AD The operations performed by lACGb on any incoming data packet are exactly the same as those of lACGaS; it checks authorization by indexing its pass-table with the source address, destination address and pass identifier, then re-computes the signature to verify the authenticity of the packet contents. A successfully checked packet is delivered to the destination end-system, 3.4.4 Session Revocation A pass may be revoked for a couple of reasons: first, a normal expiration, which occurs when the Life Time condition is met, and secondly, an explicit revocation by an lACG. In the first PASS-router simply deletes the corresponding entry from its pass-table. When a packet bearing a pass computed using an expired pass arrives at the PASS-router, it is promptly discarded since the table look-up fails. In the second case, an lACG may decide for some reason that a certain pass is no longer trusted and sends a REVOKE packet to the appropriate PASS-router. The following shows an example of REVOKE packet issued by lACGb and sent to lACGaThis is further explained in section 3.5.1. REVOKE lACGb^ lACGa i EKRi^^a,[Ha,Hb,TSa,Cause] (3.9) This concludes the description of the PASS protocol. An illustration of the protocol is shown in Figure 3.4. A dotted arrow from lACGa to Hb in the figure tells

PAGE 74

65 ADa ADb Figure 3.4. An example of PASS scheme that the DATA packet is destined to Hb from Ha and trapped by lACGaC.REQ represents the request for a public-key certificate to a local certification authority. C.IACG-A represents the public-key certificate of /ACGa3.5 Review of the Protocol This section discusses several issues leading to the design of the PASS protocol, specifically in Internet environment. It also analyzes some security aspects of the protocol before assessing its cost. 3.5.1 Exception Handling There are two situations when a pass-key becomes invalid in normal circumstance: i) when the time limit is exceeded, and ii) when a pass-key is revoked explicitly. There should be a proper mechanism to handle these situations appropriately.

PAGE 75

66 Expiration of pass-key LT is the lifetime of a pass-key to be used to expire the pass-key when the given condition is met. The simplest method is by way of timeouts, that is, an explicit time limit is negotiated at setup time and a pass-key is invalidated when the time limit is exceeded. A source host should invalidate the expired pass-key and should initiate a new session with the destination by first removing the entry from its pass list. lACG should also remove the expired pass-key from its pass list and reject any incoming packets with the expired pass identifier. While this is adequate for some types of connections, provisions for other methods of pass-key expiration may be necessary. These include limits on inactive periods, number of packets and bulk data transferred. Unfortunately, expiration based on limits other than just simple timeouts is not possible without maintaining states in lACGs. In order to expire pass-keys according to any of the above criteria requires that an lACG maintain running tally of packets, data bytes or the time of last packet arrival on a per pass-key basis. Revocation Pass-key termination by explicit request from an lACG should be viewed as more of exception than the norm as, ordinarily, pass-keys are terminated by exceeding some limit negotiated at the time of issuance. An explicit pass-key revocation can happen when an lACG decides for some reason (in circumstances where there is suspicion of a pass-key's compromise) that a certain pass-key is no longer trusted. A REVOKE packet is sent to the counterpart lACG in this case and the entry should be removed

PAGE 76

67 from both of the pass-key lists. Thereafter, both lACGs have to ensure that no more packet traffic belonging to the revoked pass-key connection passes through. 3.5.2 Design Issues in Internet Environment There are several design issues which are related to the Internet environment: packet formats of PASS-IP with current and next version of IP standards, coverage of packet signature, and datagram fragmentation. PASS packet format PASS data packet format with current IP (Version 4) standard is shown in Figure 3.3. Pass-ID and pass are stored in IP option field. Pass-ID takes 32 to 64 bits depending on the granularity of the timestamp, and pass takes either 64 bits with DES or 128 bits with MD5. Total packet length overhead will be 160 bits per packet when a 32 bit timestamp and the MD5 algorithm are used. There are two specific headers that are used to provide security services in IPv6 [69]: the IP authentication header (AH) [70] and the IP encapsulating security payload header [71]. The IP Authentication Header, which is used to implement PASS scheme, is designed to provide integrity and authentication without confidentiality to IP datagrams. The lack of confidentiality ensures that implementations of the Authentication Header will be widely available on the Internet, even in locations where the export, import, or use of encryption to provide confidentiality is regulated. The Authentication Header has an authentication data field which can contain a variable number of 32-bit words. This field is used to contain pass and pass identifier as shown in Figure 3.5.

PAGE 77

68 IP DATAGRAM IPv6 Header Hop-by-Hop/Routing Header Authentication Other Header Headers Upper Protocol 0 15 16 3l' NEXT HEADER LENGTH RESERVED SECURITY PARAMETER INDEX PASS IDENTIFIER PASS Figure 3.5. IP Version 6 authentication header containing pass As shown in example IP datagram in Figure 3.5, the AH may appear after any other headers that axe examined at each hop, and before any other headers which are not examined at an intermediate hop. Coverage of packet signatures A typical network-layer header contains addressing information such as source and destination end-system addresses, packet sequence number, packet length and other fields as the IP datagram header shown in Figure 3.3. Any header field not covered by the packet signature leaves a potential covert channel, since an intruder could trap a valid packet, change the unchecked field, and forward the modified copy without raising suspicion. We could protect against this by including the entire

PAGE 78

69 network-layer header under the packet signature, but in most internetworking protocols there are some header fields (e.g., header checksum and time-to-live (TTL) field) that are modified by the intermediate routers, and hence cannot be included in the signature. Therefore, these fields should be masked when the packet signature is calculated. Another issue has to do with the addressing information in the network header. Recall that pass-keys are issued on the basis of the source and destination end-system addresses. As described in previous section, each PASS data packet carries a pass identifier. This identifier is stored alongside the two end-system addresses in passtables of both lACGs. Since an lACG still has to consult its pass-table to look up the pass-key, it can (inexpensively) verify the Ha, Hi, addresses as well. Therefore, it can be argued that end-system addresses and other information (e.g., type-of-service, transport protocol, etc.) that is stored in the pass-table entry does not need to be protected by the packet signature. Fragmentation In a number of internetworking protocols (e.g., IP) a router may have to fragment a packet if it cannot be transmitted in a single unit. Even though fragmentation is not a unique problem with PASS protocol, data signatures complicate the use of fragmentation since the fragments must appear to have been signed by Hare, but the signatures would have to be computed by the fragmenting router. But with publickey signatures like PASS, this is impossible, since only the originating end-system

PAGE 79

70 can compute the signature. Fragmentation is at best a necessary evil [72]; it is almost always better to set packet sizes at Hsrc , to make the best possible use of the available bandwidth and to provide acknowledgments for each transmission unit. Although methods have been proposed for accommodating fragmentation while preserving data signatures [73] , it is always better for the source end-system to avoid sending packets that will have to be fragmented since the overhead incurred by those methods axe not trivial. One way of preventing fragmentation is to utilize one of the Internet Control Message Protocol (ICMP) messages [20]. In other words, ICMP Unreachable/Fragmentation Required error message can be used to find out the smallest maximum transmission unit (MTU) of the communication path. This ICMP Unreachable/Fragmentation Required error occurs when a router receives a datagram that requires fragmentation, but the don't fragment (DF) flag is turned on in the IP header. What we'll do is to send packets with the DF bit set. The size of the first packet we send will equal the MTU of the outgoing interface, and whenever we receive an ICMP Unreachable/Fragmentation Required error we'll reduce the size of the packet to the next smallest MTU defined in IP standard [74]. This can be done before actual exchange of PASS packets to decide the path MTU to the destination to avoid fragmentation. Maintaining known values in local storage will reduce the communication overhead. 3.6 Overhead Analvsis In this section, I address the impact of PASS protocol on the participating entities. The overhead can be considered in two different aspects: one for systems

PAGE 80

71 and the other for network. Comparison with other schemes is provided at the end, too. 3.6.1 System Overhead At the system level, overheads are associated with the additional storage requirement for the PASS software codes and related parameters . The overheads related to the storage of software codes vary according to the type of internetwork entity (an end-system or an access control gateway) and to the programming paradigms employed in the implementation. These topics are beyond the scope of this paper and are not discussed further. On the other hand, maintaining pass-tables demands additional storage in lACGs and end-systems. Each lACG keeps valid pass-list which at minimum consists of source end-system address, destination address, pass identifier, pass-key, lifetime, and signing algorithm. Due to the limited availability of memory in lACG, it is required to keep the size of the pass-list as small as possible. This in turn requires an efficient maintenance of pass-list by removing invalid pass entry from the list in a timely manner. This depends on the efficiency of the pass revocation mechanism. Additional information such as the arrival time of the last valid packet might be needed to monitor the activities of communication sessions for detecting idle ones. An end-system must also keep a list of active passes. This pass-list is essentially the same as the lACG's pass-list. lACGs and end-systems may need to save publickey certificates of peer entities in local and remote ADs for faster access of public keys of them.

PAGE 81

72 3.6.2 Network Overhead Session initiation The number of additional packets required for establishing an external session between Ha and Hh can be traced from the sequence of events explained in previous section. It shows that there are 10 extra packets required before Ha is allowed to go into the packet forwarding phase. The first two packets, DATA and REJECT packet, can be skipped if the source end-system knows that the destination end-system is in remote AD and it has the address of local lACG, lACGaMoreover, four packets involved in getting public-key certificates can also be saved if both lACGs find each other's public-key certificates in their local cache. Therefore, only four additional packets are needed in session initiation phase in the best case. Packet forwarding Extra packets are generated only when there is a failure in matching the pass of a pax:ket transmitted between two peer entities. One extra packet is generated if the pass of a packet from Ha does not match that generated in lACGaTwo extra packets will be generated if the pass of a packet from Ha does not match that generated in lACGbOther overhead in this phase include the additional fields in data packets, table look-ups in lACGs, and pass computation in end-systems and lACGs. The pass identifier is 32-bit quantity which is typical for a timestamp in internet protocols. The size of the pass depends on the signature method agreed by Algor field in PASS-GRANT packet. For now, it is either 64 bit DES key or 128 bits for MD5 secret prefix/suffix.

PAGE 82

73 3.6.3 Comparison with Other Schemes First, the number of extra packets generated for each external session in PASS scheme, which is at most 10, is substantially smaller than the other two schemes. The author of the VISA scheme illustrated the visa acquisition phase for a pairwise connection with an example and concluded: 'For the illustration given above, a minimum of 15 extra packets are generated before the first user packet gets through, not including the packets that comprise the authorization/authentication conversations between hosts and ACSs. Note that all of these control packets will be of minimal length.' That is, this scheme may introduce well over 20 extra packets in session initiation phase With Iqbal's scheme, there are 21 extra packets required before the local host was allowed to go into the packet control mode to transport packets to the remote network. Moreover, this number of extra packets is derived with the assumption that the transit network gateways do not enforce the access control procedures. Obviously, if the number of interconnected networks increases and the access control procedures are implemented in each of the transit networks, the overhead will increase dramatically.

PAGE 83

CHAPTER 4 INTER-DOMAIN AUTHENTICATION WITHOUT AN ARBITER 4.1 Motivation Most of existing interdomain (or inter-realm) authentication protocols assume the existence of a trusted third party as an arbiter between two authenticating principals [31, 33, 34, 46]. That is, they assume there is a trusted Authentication Server which shares a unique master key with each of the principals. The AS is capable of producing good session keys and sending them securely on the requests of principals. This assumption simplifies the interdomain authentication problem into a intra-domain authentication. Other interdomain authentication protocols are either based on a proxy (or delegation) concept or using hierarchical authentication. The former achieves the interdomain authentication through a chain of trust between authentication servers. Any broken link on the chain might annihilate the service. The latter approach suggests a hierarchy of access control servers which can perform interdomain authentication through cascaded authentications at multiple levels [46]. However, it is not always reasonable to assume the existence of a trusted authentication server between any two ADs in the internet environment. More often, there is no trusted third party between ADs which need to authenticate each other in internetworks. 74

PAGE 84

75 The interdomain authentication protocol presented here does not require any trusted third party in between. This interdomain authentication protocol, which is essential in interdomain access control schemes, is based on a public key encryption system. Public keys of peer principals are provided by ISO standard 9594-8/ITU-T X.509 Directory Authentication Service [37]. This removes the need for a globallytrusted authentication server (AS) which is not quite realistic in internetwork environments. This also alleviates the security threats found in Iqbal's scheme [30] where RSA private keys should be shared between peer communicating entities. Some of the important design principles which differentiate interdomain authentication from intra-domain authentication are listed below: • The message complexity and encryption overhead should be reduced as much as possible so that it is feasible to implement in interdomain communication. • The use of timestamps, although effective in reducing the message complexity, should be used carefully in an interdomain authentication, since the existence of proper clock synchronization among multiple machines is much more difficult to guarantee if the machines reside in different administrative domains. • Interdomain authentication should be transparent to principals. That is, the mechanisms designed for interdomain authentication should not interfere with the existing intra-domain authentication mechanisms at local machines. Any addition or modification of features for interdomain authentication should only affect the involved parties such as gateways.

PAGE 85

76 In the next section, several ongoing efforts on providing public-key certificate infrastructures are introduced. The descriptions of ITU-T X.509 directory authentication service and a new interdomain authentication protocol based on the service are given in the following sections. 4.2 Public-Key Certificate Infrastructure When using public key digital signature authentications each entity requires a public key and a private key. The public-key certificate is an essential part of a digital signature authentication mechanism. Certificates bind a specific entity's identity (be it host, network, user, or application) to its public keys and possibly other securityrelated information such as privileges, clearances, and compartments. Authentication based on digital signatures requires a certificate authority to create, to sign and properly to distribute certificates [75]. 4.2.1 Certificate Authorities Certificates require an infrastructure for generation, verification, management and distribution. The Internet Policy Registration Authority (IPRA) [76] has been established to direct this infrastructure for the Internet Engineering Task Force (IETF). The IPRA certifies Policy Certification Authorities (PCA). PCAs control Certificate Authorities (CA) which certify users and subordinate entities. Current certificate related work includes the Domain Name System (DNS) Security Extensions [77] which will provide signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working group is specifying an Internet profile for X.509 certificates. There is also work going on in industry to develop X.500 Directory Services which would provide

PAGE 86

77 X.509 certificates to users. The U.S. Post Office is developing a certificate authority hierarchy. The National Institute of Standards and Technology (NIST) Public Key Infrastructure Working Group has also been doing work in this area. The Department of Defence (DOD) Multi Level Information System Security Initiative (MISSI) program has begun deploying a certificate infrastructure for the U.S. Government. Alternatively, if no infrastructure exists, the Pretty Good Privacy (PGP) Web of Trust certificates can be used to provide user authentication and privacy in a community of users who know and trust each other. 4.2.2 X-509 Directory Authentication Service ITU-T recommendation X.509 is a part of the X.500 series of recommendations that defines a directory service. The directory is, in effect, a server or distributed set of servers that maintains a database of information about principals. The information includes a mapping from user name to network address, as well as other attributes and information about the users. X.509 defines a framework for the provision of authentication services by the X.500 directory to its users. The directory may serve as a repository of public-key certificates of the type discussed below. Each certificate contains the public key of a user and is signed with the private key of a trusted certification authority. Public-key certificate The heart of the X.509 scheme is the public-key certificate associated with each user. These user certificates are assumed to be created by some trusted certification authority (CA) and placed in the directory by the CA or by the user. The directory

PAGE 87

78 server itself is not responsible for the creation of public keys or for the certification function; it merely provides an easily accessible location for users to obtain certificates. The standard uses the following notation to define a certificate: Y «A»=Y{V,SN,AI,CA,Ta,A,Ap} where, F << A >> represents the certificate of an user A issued by a certification authority Y. Y{I} represents the signing of / by F, which consists of I with an enciphered hash code appended. The constituents V,SN,AI,CA,Ta,A, and Ap represent a version number, serial number, algorithm identifier, issuer CA, period of validity, user identifier, and user's public key, respectively. The CA signs the certificate with its private key. If the matching public key is known to a user, then the user can verify that a certificate signed by the CA is valid. Certificate authority Because certificates are unforgeable, they can be placed in a directory without the need for the directory to make special efforts to protect them. If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates can be placed in the directory for access by all users. In addition, a user can transmit his or her certificate directly to other users. In either case, once a principal B is in possession of the other principal A's certificate, B has confidence that messages it encrypts with A's public key will be secure from eavesdropping and that messages

PAGE 88

79 ^ signed with A's private key are unforgeable. If there is a large community of users, it may not be practical for all users to subscribe to the same CA; because it is the CA that signs certificates, each participating user must have a copy of the CA's own public key in order to verify signatures. This public key must be provided to each user in an absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in the associated certificates. Thus, with many users, it may be more practical to have a number of CAs, each of which securely provides its public key to some fraction of the users. Now suppose that A has obtained a certificate from a certification authority Xi and B has obtained a certificate from a CA X2. If A does not securely know the public key of X2, then B's certificate, issued by X2 is useless to A. A can read B^s certificate, but A cannot verify the signature. However, if the two CAs have securely exchanged their own public keys, the following procedure will enable A to obtain 5's public key. 1. A obtains, from the directory, the certificate of X2 signed by Xi. Because A securely knows Xi's public key, A can obtain A'2's public key from its certificate and verify it by means of Xi 's signature on the certificate. 2. A then goes back to the directory and obtains the certificate of B signed by X2. Because A now has a trusted copy of X2^s public key, A can verify the signature and securely obtain 5's public key

PAGE 89

80 A has used a chain of certificates to obtain 5's public key. In the notation of X.509, this chain is expressed as: Xi « » X2 « B » In the same fashion, B can obtain A's public key with the reverse chain: X2 « Xi » Xi « A » This scheme need not be limited to a chain of two certificates. An arbitrarily long path of CAs can be followed to produce a chain. A chain with N elements would be expressed as: Xi « X2 » X2 « Xz » ... « Xn » Xn « B » In this case, each pair of CAs in the chain {Xi,Xi+i) must have created certificates for each other. All these certificates of CAs need to appear in the directory, and the user needs to know how they are linked in order to follow a path to another user's public-key certificate. X.509 suggests that CAs be arranged in a hierarchy, so that navigation is straightforward. Certificate authoritv hierarchy Figure 4.1 is an example of such a hierarchy. The connected circles indicate the hierarchical relationship among the CAs; the associated boxes indicate certificates

PAGE 90

81 u«v» v«u» A B c X«A» X«C» Z«B» Figure 4.1. X.509 CA hierarchy: A hypothetical example maintained in the directory for each CA entry. The directory entry for CA X includes two types of certificates: • Forward certificates: certificates of X generated by other CAs • Reverse certificates: certificates generated by X that are the certificates of other CAs In this example, user A can acquire the following certificates from the directory to establish a certification path to B: X «W »W «V »V «Y »Y « Z » Z « B » When A has obtained these certificates, it can unwrap the certification path in sequence to recover a trusted copy of B's public key. Using this public key, A can

PAGE 91

82 send encrypted messages to B. U A wishes to receive encrypted messages back from B, or to sign messages sent to B, then B will require A's public key, which can be obtained from the following certification path: Z «Y »Y «V »V «W »W «X » X « A» B can obtain this set of certificates from the directory, or A can provide them as part of its initial message to B. Recall from the previous description that each certificate includes a period of validity, much like a credit card. Typically, a new certificate is issued just before the expiration of the old one. In addition, it may be desirable on occasion to revoke a certificate before it expires for one of the following reasons: 1. The user's secret key is assumed to have been compromised. 2. The user is no longer certified by this CA. 3. The CA's secret key is assumed to have been compromised. Each CA must maintain a list consisting of all revoked but not expired certificates issued by that CA, including both those issued to users and to other CAs. These lists should also be posted on the directory. Each certificate revocation list posted to the directory is signed by the issuer and consists of the issuer's name, the date the list was created, and an entry for each revoked certificate. Each entry consists of the serial number of a certificate and revocation date for that certificate. When a user receives a certificate in a message, the user must determine whether the certificate

PAGE 92

83 has been revoked. The user could check the directory each time a certificate is received. To avoid the delays (and possible costs) associated with directory searches, it is likely that the user would maintain a local cache of certificates and lists of revoked certificates. 4.3 A Secure and Efficient Interdomain Authentication Protocol Central to the problem of authenticated key exchange are two issues: confidentiality and timeliness. To prevent masquerade and to prevent compromise of session keys, essential identification and session key information must be communicated in encrypted form. This requires the prior existence of secret or public keys that can be used for this purpose. This protocol is based on the assumption that the two parties know each other's public key, either by obtaining each other's public-key certificates from an X.509 directory or because the certificate is found in the local cache from some previous use. The second issue, timeliness, is important because of the threat of message replays. Such replays, at worst, can allow an opponent to compromise a session key or successfully impersonate another party. At minimum, a successful replay can disrupt operations by presenting parties with messages that appear genuine but are not. 4.3.1 Notation The following notation is used throughout the description of the protocol. The notations here are used to maintain the conformity to the BAN logic [42, 47]. • A{I} denotes signing of / with A's private key.

PAGE 93

84 Message 1 Message 2 Message 3 Figure 4.2. An interdomain authentication protocol • {I}k denotes encryption of / with a key K. K can be either a public key in public key system or a secret key with a conventional encryption system. • Kab denotes a shared key between principals A and B. 4.3.2 The Protocol The message flow of the protocol is shown in Figure 4.2 and the details of the messages are shown as follows: Message 1 A^B: A, A{B, TSa} Message 2 B A : B, B{A,TSb,{B{TSa, Kab}}KA Messages A B : A,{B,TSb}K,, where, ^4(7} represents information signed by encrypting it with A's private key. U}Ka represents information encrypted by A's public key. Principal A initiates the authentication by sending B a timestamp TSa along with the identity of itself and that of the desired destination principal. The destination address and a timestamp are signed with A's private key to provide the authentication of this message. After B receives this message, it generates a session key Kab and sends it to A along with the timestamp sent by A and a new timestamp TSbThe session key is signed

PAGE 94

85 first with the private key of B and then encrypted with the public key of A. A then gets the session key by first decrypting it with its private key and then with 5's public key. Finally, A sends an acknowledgment packet which is encrypted with the session key, Kab4.3.3 Informal Analysis The first message establishes: • the identity of A, • that the message was generated by A, • that the message was intended for B, • the integrity of the message, and • the freshness of the message At a minimum, the message includes a timestamp TSa and the identity of B, and is signed with A's private key. The timestamp consists of an optional generation time and an expiration time. This prevents delayed delivery of messages. A nonce, Na, can be used to detect replay attacks. The nonce value must be unique within the expiration time of the message. Thus, B can store the nonce until it expires and reject any new messages with the same nonce. Here, TSa can be considered as a nonce which is useful when it is difficult or impossible to have synchronized system clocks. B now can safely believe that this message is generated by A since only A has the private key to sign this message.

PAGE 95

86 The second message establishes the following: • the identity of B, • that the reply message was generated by B, • that the message was intended for A • the integrity of the reply message, • the freshness of the reply message, and • the confidentiality of the session key, Kab The session key, Kat, is first signed with 5's private key and then encrypted with A's public key. The former provides the authenticity of the session key while the latter guarantees the confidentiality of the key since only A can decrypt it. The order of signing and encryption is important here, as will be further explained later. The last message confirms B that A has received the session key safely. The timestamp TSb provides the freshness proof with B. 4.4 Formal Protocol Analysis Using BAN Logic In this section, the proposed protocol is analyzed by using BAN Logic, BAN Logic is a formal protocol verification method to assure the correctness of an authentication protocol. Each message of the protocol is converted into the idealized form according to the method suggested by BAN logic [47] and is shown below:

PAGE 96

87 Message 1 A ^ B : A{TSa] Message 2 B -* A : B{TSb,{B{TSa,A^^''B}}Kj Messages A^B: {B,TSb,A^^' B}k,, The idealized messages correspond quite closely to the messages shown in the original protocol. The cleartext communication has been removed throughout since it provides no guarantees of any kind. The sender information from the first two messages has been removed since it does not contribute to the beliefs of the recipient. As usual, the timestamps TSa and TSb are viewed simply as nonces in the idealized protocol. Message 2 may tell A, who knows the key K~^, that Kab is a key to communicate with B. The initial assumptions of the protocol in BAN logic notation are: Key l.A A 2.B ^'S B 3.A B LB A f>.A^{B^ A^ B) G.B^A^'B Freshness l.A ^ ^{TSa) 2.B ^ ^{TSb) The first four assumptions in the key group tells that each principal knows its own secret key and the other's public key. The next two show that B has invented a new key, and that A trusts B to invent the good keys. The two assumptions in the

PAGE 97

88 freshness group tell that each principal can verify and thus believes the freshness of timestamp it generated. The formal proof of the protocol using the postulates of BAN logic is presented as follows. First, A sends a signed timestamp to B and B sees it: B < A{TSa} This and the fourth key assumption gives the following through the message-meaning rules: B^A\^TSa And B can decrypt this message since it has A's public key. B
PAGE 98

89 A < B{TSa, A B} This and the third key assumption give the following through the message-meaning rules: A]^ B \^ A^' B From the freshness assumption, A knows that TSa is fresh. This guarantees the freshness of the shared key A <4'' B. This freshness and the belief established just before give the following via the nonce-verification rule: A^B^A^'B Finally, this and the assumption of 5's jurisdiction over A ^ B together give: A^A^^' B Message 3 gives the following through the freshness and nonce-verification rules: B^A^A^^'B

PAGE 99

90 In conclusion, the final beliefs of both principals achieved by this protocol are: A^A'h" B B^A^' B A^B^A^'B B^A^A^^'B which are exactly the formalized goals of authentication for all authentication protocols as recommended by the authors of BAN Logic. These goals are achieved with only three messages. Note that the session key in the second message is signed first with B^s private key before it is encrypted. That is because although Kab has been transferred in a signed message, there is no evidence to suggest that the sender is actually aware of the data that he sent in the private part of the message. This corresponds to a scenario where some third party intercepts a message and removes the existing signature while adding his own, blindly copying the encrypted section within the signed message. In other words, the last part of beliefs cannot be established without signing before the encryption of the session key [68]. 4.5 Preventing Replav Attacks Since the destination address B in the last message guarantees the uniqueness of his own timestamp TSb, he can be sure that this message is linked uniquely to this instance of the protocol in a timely fashion. Consider an attack scenario with a version of our authentication protocol which does not include B in the last message as ITU-T X.509 three way protocol [37]. This version of the protocol just sign the

PAGE 100

91 Figure 4.3. A scenario of a replay attack last message with A^s private key instead of encrypting it with the session key. One might hope that the use of TSb would be sufficient to link the third message to the first, since TSb links the last two messages and TSa links the first two messages. The error here is that TSb alone does not link the last two messages, and this allows an intruder C to replay one of i4's old messages. The following concrete exchange which is also shown in Figure 4.3 illustrates the flaw. The timestamp TSb is not secret, and there is nothing to prevent C from using the same value in an instance of the protocol between A and C. If C is able to cause A to attempt authentication with C at the required time, the following sequence of messages can result. The intruder first contacts B: Message 1 C B : A, A{B, TSa} This is an old message originally sent by A. Remember that B is not presumed to

PAGE 101

92 check the timestamp TSa as it is used here as a nonce, and so, will not discover the replay of A's original message. Message 2 B ^ C : B,B{A,TSi„{B{TSa,Kab]}Ka] B replies as though the message came from A, and provides a new timestamp, TSi,. At this point, C causes A to initiate authentication with C, by whatever means. Messages A^C: A,A{C,TS',] A has now initiated authentication with C. The exact content of the message is immaterial. C replies to A^ providing the timestamp TSi,, which was originally provided by B. Message 4 C ^ A: C,C{A,TS,,{C{TS',,K,,})k^ A replies to C, signing the exact message needed for C to convince B that the first message was sent recently by A, and is not a replay of an old message. Messages A ^ C : A,A{TSb]

PAGE 102

93 This message is now being sent to 5 by C without any problem. Message 6 C B : A,A{TSb} The three-way authentication protocol suggested in ITU-T X.509 service [37] has this security flaw. This kind of replay attack is not possible with the proposed interdomain authentication protocol. 4.6 Variations of the Protocol Some minor modifications with the original protocol might reduce the effort of encryption without affecting the security of it. In other words, the second message of the original protocol can be rewritten as: Message 2a B ^ A : B,A,TSb,{B{TSaJ
PAGE 103

94 destination lACG and the destination lACG verifies the identity of it. With successful authentication, the verifier issues a pass-key and distributes it to the claimant for later use. This pass-key is an one-way pass which authorizes a communication session between a specific source and a specific destination end-system. The other direction of traffic between the same pair should be authorized separately by following the PASS protocol. The following protocol is intended for one-way authentication and signed secure distribution of pass-key which is used to generate pass stamps in packet forwarding phase of PASS protocol. Message 1 A ^ B : A, A{B, TSa} Message 2 B ^ A : B,{B{TSa,Kab}}K. As in the original protocol, the first message establishes the following: • the identity of A, and that the message was generated by A, • that the message was intended for B, • the integrity and freshness of the message The PASS-REQUEST message described in previous section acts as the first message in this authentication protocol. In the PASS-REQUEST message, lACGa and lACGb replace A and B in messages shown above, respectively. The only difference is the destination in the PASS-REQUEST message is not lACGt, but Hb. This is because lACGa may not know the address of lACGb when it sends this message.

PAGE 104

95 This does not make any difference since the message is supposed to be trapped by lACGb for the lack of a proper pass-stamp on it. This message thus permits both parties in a communication to verify the identity of the other. This reply message includes the timestamp sent from A, TSa and an encrypted pass-key KabKab is is encrypted with A's public key and sent to A to be used in generating pass stamps for the packets destined to B from A. This second message is implemented as the PASS-GRANT message in PASS protocol. If B wants to send a packet io A, B should go through the similar steps to be authorized to do so. 4.6.2 Mutual Authentication with OneWay Pass The following protocol is intended for mutual authentication and signed secure exchange of pass key. That is, a two-way authentication is performed between two principals at once and each direction of the communication session is assigned a distinct pass-key. Message! A^B: A,A{B,TSa,{A{Kba]]K,} Message 2 B-^A : B,B{A,TSb,{B{TSa,Kba,K,b}}KA Messages A B : A,{B,TSb}K^, Here, Kab represents the pass-key issued by B and assigned for the traffic flowing from A to B. Kba is for the other direction of the traffic between A and B. The first message establishes the identity of A, that the message was generated by A, that the

PAGE 105

96 message was intended for 5, the integrity and freshness of the message, and finally the secrecy of the pass-key, Kba. Similarly, the second message establishes the identity of B, that the reply message was generated by B, that the message was intended for A. It also assures the integrity and freshness of the reply message, and the privacy of the pass-key, KabIt also confirms A that B received the session key Ki,a safely. The last message confirms B that A has received the key safely. This protocol could be further simplified by omitting this message.

PAGE 106

CHAPTER 5 SECURE CONTROL OF TRANSIT INTERNETWORK TRAFFIC 5.1 Motivation Chapter 2 discussed the problem of simply extending stub access control schemes to transit cases; although it is straightforward, the approach does not scale well to an internetwork where many ADs, both stub and transit, want to control traffic flows. For example, visa acquisition and route setup must be repeated (or adapted) each time an involved visa-router goes down. Moreover, a source AD has no way of determining if it will be issued a visa without incurring the overhead of contacting the particular ACS in question. This is because transit control is related to packet routing. Therefore, controls for transit should be incorporated into the route calculation itself, not only into the packet forwarding function. On the other hand, policy routing allows ADs to interconnect to the global internet while still protecting network resources from general unconstrained use. However, policy routing mechanisms do not preclude the need for network access controls in the border routers of ADs that wish to control access to individual end-systems. Moreover, the PR schemes, as described thus far, rely on post-facto detection of abuse, and are in that sense less secure than straightforward network access control 97

PAGE 107

98 schemes. Most of work in policy-beised protocol development is being conducted with such environments in mind [49, 59, 60]. This chapter addresses environments where post facto detection is not adequate or possible in a timely manner. In particular, it addresses the design and costs (i.e., performance and manageability) of incorporating more defensive, preventive security measures into IDPR protocol for controlling internetwork traffic. 5.2 Security Issues in Transit Control This section identifies the potential security threats faced by the PR schemes and describes the mechanisms needed in a secure protocol. 5.2.1 Security Threats The threats to the security of PR protocols are due to the possible attacks on the routing information and data packets. An intruder may distribute false routing information in order to disrupt communication or to eavesdrop on communication. The former can be achieved by creating routing loops and the latter by rerouting traffic to a specific location. Attacks on control and/or data packets can lead to unauthorized resource usage, unauthorized communication, and inappropriate accrual of charges. These attacks can be further classified as: • Falsification of control information: this affects the route setup and packet forwarding parameters in addition to the usual network layer information such as source and destination addresses, data size.

PAGE 108

99 • Falsification of data: the data portion of a packet can be modified or replaced by an intruder. • Replay: previously-recorded legitimate packets can be replayed by an intruder. Two sources of replay are of equal concern: accidental replay due to the stuttering of a misbehaving machine, and malicious replay due to a misbehaving person attempting a denial of service attack. In IDPR, these security attacks can take the form of distributing falsified Policy Terms causing invalid Policy Routes to be computed. An intruder can also intercept a legitimate PR header and substitute an invalid Charge Code. Hereafter, the IDPR proposal is used as the foundation for our protocol design. It provides the finestgrained control through the use of AD-level source routes. Moreover, this greater control provides a wider range of possible attacks. Hence, security issues that arise in this proposal form a superset of those in the BGP approach. 5.2.2 Cryptographic Tools As discussed in previous section, we are concerned primarily with data integrity and source authenticity of exchanged messages. Confidentiality of user data is not a unique problem to the transit access control case and therefore, left to end-toend mechanisms [6]. Confidentiality of routing control information is a less general requirement than integrity and authenticity, and is discussed briefly.

PAGE 109

100 Signed one-way hash functions One of the efficient and effective ways of providing data integrity and source authenticity is to use a signed one-way hash function. That is, for each message we compute Fhash{Data) where Data includes the invariant portions of the packet header (i.e., those fields that do not change en route between source and destination) and the packet data. The resulting value is then signed. If a public key scheme is used then the value is signed with the private key of the originator. The resulting value is referred to as the packet signature. Anyone needing to verify the message integrity and sender authenticity computes FhashiData), decrypts the packet signature with the public key of the sender, and compares the two values. If a conventional encryption scheme is used, Fhash{Data) is encrypted and decrypted with the secret key to produce and verify the signature, respectively. The scheme is efficient because only Fhash{Data) needs to be encrypted, and computing the one-way hash function is faster than encrypting. As a result, the difference in processing overhead between public key and conventional encryption schemes is reduced. Throughout the reminder of this section, Rivest's Message Digest algorithm MD5 [62] is used as an example one-way hash function. MD5 has an additional calculation step and hence somewhat slower to execute than MD4. Rivest felt that the added complexity was justified by the increased level of security afforded. In addition to being the fastest method available currently, it is also being used as

PAGE 110

101 a basic data integrity mechanism in several other contexts, most notably, PrivacyEnhanced Electronic Mail [76, 78, 79, 80]. Processing speed for MD5 implementations on a 33 MHz intel 80486 machine is about 174 megabytes/second [81]. For an 1000 byte packet, this translates into an overhead of 5.7/is per packet. Encryption svstems In general, conventional encryption is not well-suited for an environment such as Link State routing where routing updates are broadcasted to a large number of recipients. Sharing a single common key amongst all nodes affords little protection, while distributing pairwise keys to each AD-pair is impractical. The alternative is to use public key encryption for the distribution of PTs. At first glance, this might appear problematic because current public key technology is still inferior in terms of performance.^ However, if we are concerned only with the integrity and authenticity of routing information then the signature mechanisms described in above can be used with little performance impact. Moreover, one of the central assumptions in the IDPR proposal is that policies change relatively slowly. Any added processing time associated with public key encryption is counter-balanced by the ubiquity and efficiency of being able to generate a single unforgeable packet signature which can be authenticated by any recipient. BGP has a similar requirement for authenticity and integrity (and, possibly, confidentiality) of routing information. However, because it is a distance vector protocol, routing updates are distributed to a much smaller number of destinations, 'In software, DES is about 100 times faster than RSA. These numbers may change slightly as technology changes, but RSA will never approach the speed of a symmetric algorithm [81].

PAGE 111

102 that is, only the direct neighbors of the originating router. At the same time, each message is considerably larger (equivalent of a complete routing table) than in the link state algorithm. Conventional encryption may be more appropriate in this case since the number of keys needed per policy router will be small, hence, easy to manage. Moreover, if confidentiality is desired, conventional encryption will save considerably on processing time. 5.3 Description of Security Mechanisms This section describes the security mechanisms which are added to IDPR protocol in order to make it a secure transit control scheme. Security mechanisms are described for each of three phases of IDPR: Policy Term distribution, route setup, and packet forwarding. The following notation is used throughout the description of the protocol: « • II is the concatenation operator as in A" || Y. • N denotes the length of a PR, that is, the number of ADs in a PR. • ADi{0 < i < N) denotes the i-th AD in a PR, ADo = AD„c, and ADn = ADdsf • Kij denotes a secret key shared by ADi and ADj. • Kaig denotes a secret key used for computing data signatures. • KUi, KRi denote public (encryption) and private (decryption) keys of ADi.

PAGE 112

103 • Efc[Data], DK[Data] denote encryption and decryption, respectively, of Data with key K. • EKRi[Data], DfcUi[Data] denote signing and verification, respectively, of data using public key system. • Fhash{Data) is a one-way has function of Data. 5.3.1 Secure Distribution of Policy Terms The first phase in secure transit control is the PT distribution stage. The security mechanisms to assure integrity and authenticity of PTs are disscussed. The replay prevention and the confidentiality of PTs are discussed after that. Maintaining integrity and authenticity of PTs In order to provide for secure distribution of Policy Term updates, each AD must be able to sign its own PTs. It also needs to know how to authenticate incoming PTs. Because of the Link State nature of the protocol, each PT update must be flooded to ADs throughout the internetwork so that all participant ADs can use them in their PR computation. Before using a new PT, each AD needs to verify the authenticity and integrity of its contents. This is difficult to achieve in a conventional encryption environment, as the number of potential recipients of a PT update can be quite large. The secure version of PT signed by ADi is shown below where public key encryption and the certifying authority mechanisms described in RFC1421 [82] are used for this particular function.

PAGE 113

104 SecurePT = [PT \\ PTSIGi] PTSIGi = EKR.[FhashiPT)] Preventing replay of PTs An intruder can replay previously recorded PTs which can lead to incorrect route calculations in recipient domains. There are two basic approaches for countering replay attacks: (i) nonce identifiers, and (ii) timestamps. Each SecurePT can carry a nonce or timestamp supplied by the source entity. The main disadvantage of using nonces is the difficulty in their verification. In particular, each policy gateway (PG) needs to keep a complete history of past nonces which makes the verification inefficient. Timestamps are much better suited for this application. First, clocks need not be synchronized continuously between the source and the transit PGs. This is because the time interval of any two successive PT update packets are relatively large compared to the granularity of clock synchronization. This is based on one of the assumption of IDPR: policies and inter-AD connectivity change relatively slowly. Maintaining confidentialitv of PTs Routing information distribution is one area of policy routing where confidentiality measures might be considered useful. However, it implies that the entire routing

PAGE 114

105 update must be encrypted separately for each anticipated destination AD. In general, this is impractical regardless of the type of encryption used. Since a link state update is flooded throughout the internetwork (in this case, to all ADs), the number of potential destinations can be quite large. In order to achieve confidentiality in this environment, the source of a link state update needs to encrypt the update T times (where T is the total number of ADs). Furthermore, the traffic due to update propagation will increase T-fold. 5.3.2 Route Setup Phase The route setup phase requires that each intervening AD have means to forward subsequent data packets along a specific Policy Route. As described in IDPR proposal, each AD along the route must be supplied with the next hop AD at PR setup time. The purpose of PR setup is to establish state in all intervening PGs so that Policy Routing decisions can be made in advance of the actual communication, and subsequent data packets can carry a minimum of PR-related information, thus, reducing the overhead and latency. In addition, in a secure PR scheme, each AD must be able to authenticate and authorize a PR. Authentication means verifying that a PR was issued by a recognized entity, and was not tampered with. Authorization entails making sure that a PR conforms to a local policy. This PR authentication provides protection from possible security attacks. First, it protects from fabrication or modification attacks on PRs. In order to achieve this, each PR must be traceable to the issuing AD. In other words, it must be signed

PAGE 115

106 with an unforgeable signature. For all intervening ADs, this would provide for nonrepudiation of issuance and sender authenticity. It also protects from replay of previously issued PR setup packets. This can be prevented if a timestamp is included within each PR setup. The signature of a PR setup packet becomes dependent on this timestamp, and, makes replay detection possible within the granularity of the timestamp and clock synchronization. As the number of setups is relatively small compared to the number of data packets, relatively coarse timestamp granularity (e.g., 1 ms) should be adequate and is preferable to the management required to keep track of unique sequence numbers also referred to as nonces. Secure PR setup As with PT update distribution, we are concerned with data integrity and authenticity of setup packets. However, unlike PT updates, PRs are set up frequently, and increased latency is experienced directly by end users. Thus, we are far more concerned with the per-signature overhead for setup than we are for PT distribution. Consequently, the use of both conventional and public key encryption signature mechanisms will be investigated. As discussed earlier, conventional encryption implies a significant key management burden, since an AD has to share a secret key with every other AD that it ever communicates with. Moreover, it entails computing a PR signature for every AD involved, whereas a single PR signature verifiable by all intervening ADs is sufficient in public key encryption. A signed PR setup packet is calculated as such:

PAGE 116

107 SecurePRSETUP = [PRSETUP \\ PRSIGsrc] PRSIGsrc = EKR,jFhash{PRSETUP)] where Ekr,,.c[I] denotes the signing of / with private key of ADarcGiven a strong one-way hash function (such as MD5) and a strong encryption function (such as RSA), this signature is sufficient to maintain the integrity of the PR setup packet. Timeliness can be maintained by timestamping the setup packet. On the other hand, a typical PR traverses a relatively small number of ADs (N is much less than the diameter of the internetwork). This makes conventional encryption a viable choice since a PR would only have to be signed N times. A signed PR setup packet, in this Ccise, is shown as: PRSIGi = EK,,JFHash{PRSETUP)] Providing data packet integrity If data packet integrity is desired, the issuing ADsrc needs to generate a new data signature key, Ksig, for use in whatever per-packet data integrity variation is used. Kgig must be communicated in secret to each ADi. This requires that ADsrc encrypt K^ig N times, that is, compute EKuAKsig] for all ADi.

PAGE 117

108 When the PR setup packet propagates along the route each ADi obtains Ksig by decrypting it with ADi^s private key. Then each ADi recomputes and verifies PRSIGsrc, and validates the timestamp (possible, by comparing it to the timestamp of the previous setup packet, which it may choose to keep). It then proceeds to authorize the PR. At this point, each ADi is assured that: • the PR is valid, in other words, does not violate local policy, • the PR is authentic, that is, issued by a recognized entity, and • the PR is fresh, that is, issued recently. 5.3.3 Packet Forwarding Phase After a PR has been set up, subsequent data packets can take advantage of the PR state in intermediate ADs. First, instead of a full PR, each data packet carries only an abbreviated version referred to as the PR header. Second, the state in all intervening PGs allows them to bypass expensive authorization checks on a per packet basis. A PR header only needs to contain the information necessary to identify the appropriate state in intervening PGs. Its exact contents are described in the next section. Maintaining integrity and authenticitv of data packet Assuming appropriate security measures to prevent PR setup threats above, there remains the possibility of malicious attack at packet forwarding time: an intruder located at some point along a PR can copy a valid PR header from a legitimate

PAGE 118

109 packet, attach its own data and send it along a PR, thus, obtaining service fraudulently. This attack can be remedied if each data packet is signed by the source. SecureDATA = [PRHEADER \\ DATA \\ DATASIG] PRHEADER = [AD,rc \\ PG„c \\ TSsrc] DATASIG = EK,„[Fhash{PRHEADER || Packet)] Depending on the type of encryption used, the overhead incurred by signing each data packet (or even a hash function thereof) can be prohibitively high. Perpacket overhead includes the signature computation at the source and its subsequent verification at each PG hop en route to the destination. If only sender authenticity and data integrity is desired, then the tradeoff between conventional and public key signature of the hash function is dependent upon their relative speeds. In order to minimize per packet processing overhead, we will assume the use of conventional encryption for data packet signature computation. In this case, a secret key Kgig is distributed during setup for use in data integrity verification. This key is shared by all ADs on the route. As a result, a simple group channel is established. However, it is possible for any AD along the route to masquerade as the source AD for the duration of that PR. Moreover, the secret key must be distributed without disclosure. This requires the public key scheme to encrypt the key multiple times separately with the public key of each AD in the PR.

PAGE 119

110 Prevention of data packet replay An intruder can replay previously recorded data packets which can lead to unjustified charging and/or denial of service. We only need to protect against replayed packets within the hfe-span of the associated PR. After a PR expires or is closed, all packets carrying the expired PR identifier will not be processed. There are two basic approaches for countering replay attacks: (i) nonce identifiers, and (ii) timestamps. The main disadvantage of using nonces is the difficulty in their verification. In particular, each relevant entity (each PG, in our case) needs to keep a complete history of past nonces which makes the verification inefficient. Timestamps are much better suited for this application. First, clocks need not be synchronized continuously between the source and the transit PGs. This is because a PR setup packet is timestamped; its timestamp can be used as a lower-bound for subsequent data packets in all intervening PGs. Furthermore, if the intervening PGs maintain a more current lower-bound timestamp {t lower), opportunities for replay can be reduced further. Consider the following simple protocol: 1. When a PR is issued, PGarc timestamps the PR setup packet, and distributes the timestamp, tsetup, in a secure fashion to all intervening PGs in transit ADs. All transit PGs initiahze their tiower values for this PR to tsetup2. When a data packet is sent, the originating PG timestamps its PR header with tdata-

PAGE 120

Ill 3. When this data packet reaches a transit PG, its PR header is examined and the tdata is compared to t lowerThree outcomes are possible: (a) tdata < tiowerthe difference between the two values is examined. If it is less than some (locally defined) threshold, St, the packet can be forwarded. Otherwise, the packet is discarded. (b) tdata > tiowerthe packet is forwarded and tiower is set to tdataOf course, a PG may get suspicious if the difference is too large. (c) tdata — tiower'this Can occur when two successive data packets belonging to the same PR stream carry the same timestamp. To distinguish between such packets, it would be necessary to keep additional information such as a packet signature, for the last data packet processed. However, it is desirable for the clock rate to be at least as fast as the maximum packet rate. This would preclude duplicate timestamps on data packets. This protocol prevents most, but not all, replay attacks. In order to prevent all replay attacks, 6t values must be set to zero in all transit PGs, which would essentially disallow any out-of-order data packets. This is a choice that will not be practical for environments where out-of-order packets are a frequent occurrence. 5.4 Cost of Securitv Mechanisms Our purpose in this section is to investigate bounds on achievable data rates with the security schemes described above. We can identify four important overhead contributors listed in the order of magnitude:

PAGE 121

112 • Per Packet Signature Overhead • Increased Packet Length • Setup Overhead * • Other Additional Per Packet Processing In the remainder of this section we analyze each of the above contributing factors in several variations of the general scheme. 5.4.1 Per Packet Signature Overhead Per packet signature costs are largely dependent upon the particular variation of data integrity checking. Latency is a much more critical concern with respect to forwarding of data packets than in the case of PR setup. For this reason, many ADs are likely to forego per-packet signature and verification of most traffic. N hash calculations and encryptions are needed per packet if all the transit ADs verify the packet integrity. There are other possibilities whereby ADs can trade the level of protection for the amount of overhead incurred. A spectrum of modes of packet verification and corresponding costs are given below: • Full Transit Verification: In network environments where data integrity and security concerns outweigh the overhead of extra processing, the data portion of every packet is subject to forgery and must be checked (for authenticity and integrity) at each hop on its way to the destination. Every data packet is signed at the source and checked at each AD hop en route. A'^ + 1 hash calculations and A'' + 1 encryptions are needed per packet.

PAGE 122

113 • No Transit Verification: If authenticating data in each packet at every hop is prohibitively expensive, end-to-end data integrity similar to that in stub access control schemes may be appropriate. Every data packet is signed at the source but is checked only at the destination. This approach has limitations, most notably the fact that the modification attack will not be detected until the packet reaches the destination AD. This can result in unauthorized use of transit resources and, inappropriate billing of the source. On the other hand, this approach benefits from lower per packet latency (2 hash calculations and 2 encryptions) which is independent of the PR's length. • Selective Transit Verification: If No Transit Verification exposes transit resources to excessive misuse, yet Full Transit is too expensive, some selected ADs can perform data integrity checks. Every data packet is still signed at the source, but only selected transits and the destination check the signature. The source AD can designate at PR setup time some specific transit ADs to perform data integrity checks, k + 2 hash calculations and k + 2 encryptions are needed when k transit ADs are designated. • Selective Packet Verification: Instead of each transit AD having to authenticate each packet, it may suffice to authenticate every m-th packet.^ In the simplest version of this patterned authentication scheme, ADsrc would choose m at random from a locally defined range of values and then specify m during ^Alternatively, transit ADs can choose their own values or probabilities to verify transit packets selectively. In this case, all data packets are signed at the source.

PAGE 123

114 route setup. In this scheme only 1/m data packets are signed at the source and the same 1/m packets are checked, and therefore, {N + l)/m hash calculations and (N + l)/m encryptions are required. In return for reduced overhead, if the value for m is discovered by an intruder then (m — l)/m of the PR's bandwidth can he abused. Moreover, this method implies that care must be taken to recover from lost and out-of-order packets. 5.4.2 Packet Length Overhead Increased packet length is incurred by the PR header carried in every data packet. It is anticipated that the length of this header will be on the order of 32 bytes. When the replay prevention is used independent of the data authentication, the cost amounts to one additional PR header field (32 to 64 bits depending on the timestamp granularity). 5.4.3 Setup Overhead PR setup is accomplished by composing and sending a packet containing the entire PR as described above. The costs include: • N conventional encryption operations by ADsrc to encrypt K^ig for each intervening ADi, if data integrity is checked en route. • A hash function computation over the entire PR setup packet followed by a single pubhc key signature computation of the 128-bit hash value. • N hash function computations and N public key signature verifications for verifying the setup packet signature en route.

PAGE 124

115 • A'^ conventional decryption operations by each ADi to decrypt Kaig. However, this can be done after the setup packet is forwarded to the next hop and so does not contribute directly to the setup latency. 5.4.4 Other Per Packet Processing Costs Additional (other than encryption) processing costs are incurred mainly by the added logic in routers for processing of PR-based packets, in particular, table lookups. Generally, the time spent on lookups is far overshadowed by the encryption costs.

PAGE 125

CHAPTER 6 CONCLUSIONS AND FUTURE WORK Security has become one of the most important research topics in internetwork environment, and more in-depth exploration and investigation into different aspects of computer and internetwork security are needed. In this dissertation work, significant research results have been shown by either enhancing the performance (efficiency) or increasing the power (effectiveness) of the access control and authentication services and mechanisms. Conclusions of these works and possible future tasks are discussed individually on each research area. 6.1 Internetwork Access Control First, a design and analysis of a secure and efficient internetwork access control scheme entitled PASS is presented. PASS enforces access control policy on packet (i.e., network layer) level. This packet-level approach is more efficient and flexible than a high-level gateway approach since the high-level control suffers from high-level processing overhead and requires a separate gateway function for each application it supports. PASS is designed for the environment where simple source/destination filter and access control list are not sufficient to enforce policies due to the dynamic nature of the internetwork and insufficient logical information in the addresses used. PASS incurs less communication overhead than existing packet-level access control 116

PAGE 126

117 schemes and reduces security vulnerabilities in the interdomain authentication and key distribution stage by using public key certificates. Recently, many suggestions and proposals have come out to make internetwork transactions secure. Some of those efforts suggest modifications of some part of existing protocols and standards, and others demand rather fundamental changes to achieve the same goal. The former approaches introduce the possibility of inconsistency problems while the latter approaches quite often impose a financial and technical burden. PASS is one of the former approaches which does not require drastic changes in the system environment. PASS does not impact intra-AD communication and has no influence on the end-systems that do not partake in interAD communication. However, it also can be used as a part of more complete security service, performing low-level authorization and authentication while higher-level mechanisms provide required logical information to be used to make those decisions. One of the possible ways is discussed in the appendix which is about the integration of PASS with a firewall. 6.2 Interdomain Authentication To make an internetwork transactions secure, it is crucial to have a reliable authentication protocol between principals in different domains. A secure and efficient public-key based interdomain authentication protocol has been proposed which is used in PASS scheme. This new protocol makes use of an international standard directory authentication service (ITU-T X.509) as a public key provider. This removes an unrealistic assumption about the availability of a trusted third party used

PAGE 127

118 in most other existing protocols. The authentication goals of the protocol are verified by using BAN logic. Many known security flaws in existing standards and protocols have been addressed in this new protocol. One of these is shown in an example of a replay prevention. Two variations of this protocol are given for the situations which require one-way authentication and one-way pass. More and more security mechanisms use public key technology because of many advantages it gives. One of the most significant advantages is that it does not require on-line trusted key distribution centers. In addition to that, it scales well to a very large internetworks due to its linear complexity of key management overhead. Therefore, the proposed interdomain authentication protocol fits well in emerging internetworks which quite often composed of large number of ADs. Before the ubiquitous availability of the standard directory service, some specialized sever applications can be implemented to be used with the proposed authentication protocol. One of such servers is the Certification Distribution Center that is used to distribute public key certificates and other authentication-related information to the communicating principals. The issues of how to generate, maintain, and distribute this information could be worthwhile to explore. 6.3 Secure Control of Transit Internetwork Traffic To complement the internetwork policy enforcement scheme, a secure transit traffic control mechanism is proposed. First, some stub-network access control techniques are investigated for possible extensions of them to transit control mechanisms. From this, it is found out that controlling access to network resources in intermediate

PAGE 128

119 domains is closely related to packet routing. Next, two interdomain routing protocols are investigated, which make routing decisions based on policy attributes in addition to the conventional link metrics. Security mechanisms are added to the Inter-Domain Policy Routing protocol (IDPR) to make it a secure transit control scheme. The cost of the added security mechanisms is analyzed for several modes of transit packet verification. This work proposed security mechanisms that utilize policy routing to prevent unauthorized use of network resources, and control routing of packet data across AD boundaries. The proposed mechanisms were designed to support inter-operability across ADs with heterogeneous policies to the extent that their combined policies allow. Moreover, these preventative transit control mechanisms can inter-operate with detection-based (that is, non-secure) PR mechanisms. A stub network access control (such as PASS) is concerned with policy enforcement with respect to non-transit internetwork traffic. In other words, the issue is how an AD can control both inbound and outbound traffic at its network boundaries. On the other hand, a transit network access control is concerned with policy enforcement with respect to transit internetwork traffic. Controlling access to transit network resources (such as routers and links) requires additional protocol support because of the need to coordinate routing decisions among all intervening networks. These two access controls should work in harmony to achieve a dependable policy enforcement in internetwork environment. The integration of these two access controls could be a challenging work since they have different requirements and natures.

PAGE 129

APPENDIX A INTEGRATION OF PASS WITH GTGB In this appendix, we discuss the possibilities and related issues in combining PASS and Gemini Trusted Guard Base (GTGB) which is being setup in our Computer Network Laboratory. The GTGB prototype runs on the Gemini Trusted Network Processor (GTNP) and acts as a firewall between a set of one or more Local Area Networks (LANs) and a Wide Area Network (WAN). The GTGB prototype performs trusted separation of data at different levels and packet filtering. The GTGB prototype can be configured to keep an audit trail of violations detected during operation. The internetwork may consist of Gemini GTGB prototype systems, routers, and various workstations at different security levels. The GTGB prototype enforces an overall network mandatory security policy with the use of cryptographic seals applied to all TCP/IP packets passing through the WAN. This cryptoseal is generated using the Data Encryption Standard (DES) algorithm. A unique key may be used for each IP address pair. The cryptoseal is a function of this key, the TCP/IP packet, and the security level of the LAN port [83]. A.l GTGB Functionality Each Guard acts as a security firewall between untrusted single-level LANs operating at different security levels. The LANs connected to the Guards are not 120

PAGE 130

121 considered trusted networks because information is allowed to flow freely between various LANs via a router. The GTGB accepts and transmits information at the IP level. It examines the IP datagram header fields as well as the TCP packet header fields encompassed within. The GTGB does not perform fragmentation of datagrams, nor does it accept packets that have been fragmented between GTGB systems (i.e., within the WAN). The Guards are intended to provide six security protection mechanisms: • IP Source/Destination Address Pair Verification: Datagrams are only transferred through the Guard if they contain a source/destination IP address pair which has been configured off-line to be valid. The datagram is discarded and an audit record is generated when a datagram enters with an invalid IP address pair. • Incoming Physical LAN Port Verification: The Guard ensures that each datagram it received came in from the expected physical port. The datagram is discarded and an audit record is generated when a datagram enters from an invalid physical port. • TCP/UDP Destination Port Filtering: The Guard provides TCP/IP packet filtering based on the network services (i.e., TCP/UDP port number) allowed per physical destination port. The datagram is discarded and an audit record is generated when the packet contains a TCP/UDP destination port number below 1024 that is not allowed for a particular LAN port. The current

PAGE 131

122 design of the Guard allows all TCP/UDP destination port numbers at or above 1024 to pa^s through because these ports are generally used by reply packets. Detection of Unsolicited Public Access: The Guard detects and discards datagrams which originated from a public network that have a TCP/UDP destination port number below 1024. Detection of Data Modifications: For Private-to-Private connections, the Guard detects modifications of the content of each datagram that travels across the WAN by using the cryptographic sealing technique. The Guard generates a cryptoseal for each datagram to be sent out to the WAN, and checks the cryptoseal when receiving a datagram from the WAN. There is a separate cryptographic key used to generate cryptoseals for each valid IP address pair in the network. The datagram is discarded and an audit record is generated when a modification of the packet within the WAN is detected. Controlled Data Distribution: For Private-to-Private connections, the Guard ensures that the security level of the data is equal to the security level of the destination port. This is accomplished via the cryptoseal because the cryptoseal is a function of the port's security level. The datagram is discarded and an audit record is generated when a datagram is sent to a LAN operating at a security level that is different than the security level of the LAN from which it originated.

PAGE 132

123 For Private-to-Public connections, the Guard releases the data based on the information that is configured off-line by Mandatory Security Administrator (MSA), information that is configured off-line. A datagram (without a cryptoseal) destined to a LAN port that is not allowed to have public connections is discarded and an audit record is generated. • Audit: The Guard maintains and protects a log of auditable events. There are six security-relevant auditable events: invalid IP address pair, invalid source physical port, unsolicited pubhc access denied, invaUd TCP/UDP port permission, invalid cryptographic seal, and illegal public network access. There are two informative auditable events for Private-to-Public connections: outgoing (LAN-to-WAN) public network access, and incoming (WAN-to-LAN) public network access. Each audit record is transmitted to a printer, to the GTGB operator console, and optionally to the hard disk. A.2 Configuration of Gemini-UF GTGB Testbed All GTGB systems will have one WAN/MAN port and several LAN ports. All TCP/IP packets first travel into one of the GTGB system's LAN ports and out the WAN port. These packets then get routed by an external router back into the same GTGB's WAN port (or into another GTGB WAN port on the WAN) and out one of the LAN ports. In other words, all packets must travel from the source LAN through a GTGB system to the WAN, and then back through a GTGB system to the destination LAN. Only one network device (i.e., a router/bridge) can communicate with the Guard per port.

PAGE 133

124 Kcrbcrot ClicMi BSD clieni Linux ClicM ftf LANO BSD Server/Rouler Kcibenw Server LAN2 NdinnlPCIical Smart Card M LANl H ^ Pon302 Q^QgPort30^ NawjTC IPX WFWG Nelwire IPX/IP Servrr Ulicm [jg] LANO JML PortSOl Port30l Port303 BSD WAN Router Ml Port300 FrxBSO ScrverdicM moclungbinl GTGB FS^99?. . . , Ml LAN2 JM| \S\ FrecBSD Rouler ' ' 3 Vojoger UFCISE Rouler Alaiiick „ Porl3(X; Intemel Server Port302 nxfiR Port301 Linux Server eiiietprMe LANl =1 LAN3 FrecBSD aicu Gemini, Monterey Sacurity Laval 0 Sacurity Laval 1 UF, Gainesville Figure A.l. The network configuration of Gemini-UF Testbed The GTGB system provides protection at the IP layer of the TCP/IP protocol suite. Therefore, any application developed for the TCP/IP protocol suite can be used with the GTGB. A. 2.1 PrivateTo-Private Secure Connections The network configuration shown in Figure A.l illustrates how a pair of GTGB systems may be used to create a virtual private-to-private secure connection with trusted separation of data at different security levels over a public network. This testbed consists of seven LANs operating at two security levels ( "security JeveLO" and "security JeveLl"). Gemini LANs 0 and 1 and UF LANs 0 and 1 are operating with a level of "security JeveLO", while Gemini LAN 2 and UF LANs 2 and 3 are operating with a level of "securityJeveU".

PAGE 134

125 The intent of the GTGB system is to ensure that the data of a LAN of a particular security level is only accessible to other LANs of the same security level. For example, in Figure A.l, information may flow between Gemini's 205.179.16.68 and ds9 in UF side, but no information is allowed to flow between enterprise and ds9 at UF. This shows how one Guard system can ensure trusted separation of data at different security levels when all the LANs are located within an organization. The PrivateTo-Private connections are considered as secure connections because any information passing between the LANs across the WAN/MAN is mediated by the Guards according to the policies set by the designers of the network. A. 2. 2 PrivateTo-Public Connections This figure also illustrates how one Guard system may be used to provide controlled access to network services over a public network, including Internet. Under MSA control, one of the workstations in Gemini LAN 0 (e.g. 205.179.16.136) can be enabled to have access to the Internet. The workstation 205.179.16.136 can also communicate with other workstations in Gemini LAN 1 if so allowed by the system policy and configured by the MSA. The decision to allow a workstation that is exposed to public network access to exchange data with other workstations in the private network should only be made after careful risk and vulnerability assessment is done. With regard to Gemini LANs 0 and 1, it should be recognized that the current design of the GTGB cannot prevent certain forms of Internet attacks which may be possible on such exposed networks. It is strongly recommended that a LAN configured to allow access to the Internet operates at a dedicated security level.

PAGE 135

126 The Private-to-Public connections are also considered as secure connections because they are controlled by the MSA based on the system policy. Information flow between selected workstations and the public network is still subjected to both Mandatory Access Control (MAC) and Discretionary Access Control (DAC) enforced by the Guard. For this type of connection, there is no cryptographic checksum in the IP datagram. Hence, the integrity check on the datagram will not be performed, and the Guard will make the decision whether to release the data or not based on MSA-specified information rather than on the cryptographic checksum. A.3 Integration of PASS into GTGB Testbed There may be several different ways of integrating PASS scheme with GTGB system depending on the degree of interaction between those two. These ways are grouped in two different situations and discussed below. A.3.1 Coexistence of PASS and GTGB In this mode of integration, PASS and GTGB just coexist without any interaction between them. In other words, GTGB verifies the packets by looking up the verification table and generates/ verifies cryptoseal regardless of the type of packets (e.g., PASS or non-PASS packets). On the other hand, PASS scheme performs exactly the same functionalities as described in Chapter 3 without being hindered by the existence of GTGB. This is possible since GTGB is designed to be transparent to the local hosts and the pass information in PASS packet is not supposed to be checked by GTGB. In other words, PASS end-system talks with its local lACG without knowing the existence of GTGB between them and on the other hand, GTGB just

PAGE 136

127 verifies the packets IP addresses and port numbers without concerning the contents of IP option field except the cryptoseal. The exit authorization phase of the PASS protocol works as follows: 1. An end-system mockingbird at UF LAN 2 in Figure A.l sends a packet to 205.179.16.68 in Gemini. 2. GTGB captures this packet and verifies that the packet's source and destination IP address pair matches an entry in Address Verification Table (AVT) and verifies that the port number from which the packet was received matches the port number specified in the above entry. i) If the above checks are successful and the IP address pair is configured for Private-to-Private connection, a cryptoseal of the packet data is generated using the key from the above entry and stored within the IP header. No cryptoseal will be appended to the IP header if the address pair is configured for Private-to-Public connection. The packet is sent out to the lACG. ii) If the checks are not successful (indicating an invalid packet), the packet will be discarded. 3. The local lACG (voyager, in this example) finds out that the packet does not have proper pass and reply with a REJECT packet which notifies mockingbird that the intended destination is non-local, and that it must acquire a pass by first getting authorization and authentication from a local lACG.

PAGE 137

128 4. GTGB does the similar check on the REJECT packet and forwards it to mockingbird if the check is successful. 5. mockingbird sends an AUTH-REQUEST packet to voyager. 6. GTGB does the similar check on this packet and forwards it to mockingbird if the check is successful. 7. voyager performs authorization and authentication with mockingbird on receiving the AUTH-REQUEST packet. GTGB does the similar checks on all the packets exchanged between voyager and mockingbird during this process. From this description, we notice a possible problem and a redundancy. That is, some higherlevel mechanism might be needed to resend the packets discarded at GTGB without notifying the sender of the fact. As to the redundancy, we notice that there could be a quite amount of overlap between the AVT check of GTGB and authorization of lACG. The authorization procedure may be replaced by the AVT check of GTGB if the authorization is solely based on the access control list type of information. We will discuss further in next section. A.3.2 Interactions between PASS and GTGB In this section, we probe some possibilities of interactions between PASS and GTGB by replacing or relocating some of components of PASS scheme to GTGB.

PAGE 138

GTGB as an Authorization Server As indicated above, it could reduce overhead that the AVT check of GTGB is used as an authorization service of PASS protocol at lACG. The Address Verification Table holds the following information: • Valid IP source/destination address pairs with their respective IP address mcisks. • Physical LAN port associated with the originating LAN for each address pair. • Cryptographic sealing key for each address pair. • An indicator specifying whether public network access is allowed or not for each address pair. • A set of audit generation options for each address pair that is allowed to have public network access. Any authorization based on IP addresses and port numbers can be accomplished by the verification of GTGB and therefore, can be replaced with AVT checking of GTGB without any problem. Needless to say, the GTGB checking is more restrictive in the sense that any access permission by lACG can be denied by GTGB. Therefore, it would be a good idea to implement local access control policy in GTGB tables and let it do the authorization service for PASS scheme. Relocating PASS Components on GTGR Another possible move with GTGB is to try to use it as a component of PASS scheme. In other words, it is tempting to implement one or more of PASS components

PAGE 139

130 (e.g., Certification Authority or Internetwork Access Control Gateway functions) in GTGB and make them more interactive. However, it is not realistically possible to make changes on GTGB to make it useful with PASS for the following reasons: • First, current version of GTGB does not have router functionality. Since essentially aa lACG is a border router, we cannot use GTGB as an lACG. Not only this but for the following reason, does it not a good approach. • Second, GTGB is designed to work transparently to the local host and no endsystem can explicitly request/receive services to/from GTGB. For this reason, it cannot be used as a Certification Authority for PASS scheme. • Lastly, it is extremely difficult to modify some portion of GTGB or to add new services into it because of the security requirement. This fact also discourage the move of using it as a part of PASS.

PAGE 140

APPENDIX B ACRONYMS ACL Access Control List ACS Access Control Server AD Administrative Domain BAN Burrows, Abadi, and JNeednam BGP Border Gateway Protocol CA Certincation Authority DARPA Detense Advanced Research Projects Agency DCE Distributed Computing Environment DBS Data Encryption standard EGP Exterior Gateway Protocol GTGB Gemini i rusted Guard Base lACG Internet Access Control Gateway ICMP Internet Control Message Protocol IDPR InterDomain Policy Routing IETF Internet Engineering Task Force IP Internet Protocol ISO International Standardization Organization ITU International Telecommunications Union MD5 Message Digest 5 MTU Maximum Transmission Unit OSI Open System Interconnection OSF Open Software Foundation PAC Packet Authentication Code PASS Packet-level Access Security Scheme PG Policy Gateway PR Policy Route PT Policy Term RPC Remote Procedure Call RS Route Server TCP Transmission Control Protocol 131

PAGE 141

REFERENCES [1] D. A. Curry, "Improving the security of your unix system." technical report itstd-721-fr-90-21, SRI International, April 1990. [2] F. T. Grampp and R. H. Morris, "Unix operating system security." AT&T Bell Laboratories Technical Journal, vol. 63, pp. 1649 1672, October 1984. [3] M. Abadi, M. Burrows, C. Kaufman, and B. Lampson, "Authentication and delegation with smart-cards." Research Report 67, DEC SRC, October 1990. [4] C. P. Pfleeger, Security in Computing. Prentice-Hall, 1989. [5] S. Hares and D. Katz, "Administrative domains and routing domains: a model for routing in the internet." RFC 1136, SRI Network Information Center, Dec. 1989. [6] V. L. Voydock and S. T. Kent, "Security mechanisms in high-level network protocols." ACM Computing Surveys, vol. 15, pp. 135-171, June 1983. [7] V. L. Voydock and S. T. Kent, "Security mechanisms in a transport layer." Computer Networks, vol. 8, pp. 433-449, 1984. [8] D. Branstad, J. Dorman, R. Houseley, and J. Randall, "SP4: A transport encapsulation security protocol." in Proc. Tenth National Computer Security Conference, pp. 158-161, Sept. 1987. [9] R. Nelson, "Secure data network system (SDNS) services and architecture." in Proc. Tenth National Computer Security Conference, pp. 153-157, Sept. 1987. [10] R. Ramaswamy, "Placement of data integrity security services in open system interconnection architecture." Computer and Security, vol. 8, pp. 507-516, Oct. 1989. [11] W. Fumy and M. Leclerc, "Placement of cryptographic key distribution within OSI: Design alternatives and assessment." Computer Networks and ISDN Systems, vol. 26, pp. 217-225, 1993. [12] S. M. Bellovin, "Security problems in the TCP/IP protocol suite." ACM Computer Communications Review, vol. 19, March 1989. 132

PAGE 142

133 [13] S. Kent, "Comments on security problems in the TCP/IP protocol suite." ACM Computer Communications Review, vol. 19, pp. 10-19, July 1989. [14] S. Kent, "US DOD security options for the internet protocol." rfc 1108, BBN Communications, November 1991. [15] R. Ramaswamy, "A security architecture and mechanism for data confidentiality in TCP/IP protocols." in Proceedings of the IEEE Symposium on Security and Privacy, pp. 249-259, 1990. [16] B. Kumar, "Integrating security in inter-domain routing protocols." Computer Communication Review, vol. 23, pp. 36-51, Oct. 1993. [17] J. C. Mogul, "Simple and flexible datagram access controls for unix-based gateways." in USENIX Conference Proc, pp. 203-221, Summer 1989. [18] J. C. Mogul, "Using screend to implement IP/TCP security policies." network note nn-16. Digital Equipment Corp., July 1991. [19] D. R. SafFord, D. L. Schales, and D. K. Hess, "The TAMU security package: An ongoing response to internet intruders." in Proc. Fourth Usenix Unix Security Symp., pp. 91-118, Oct. 1993. [20] W. R. Stevens, TCP/IP Illustrated, Vol.1 The Protocols. AddisonWesley, 1994. [21] W. R. Cheswick and S. M. Bellovin, Firewalls and Internet Security. Reading, MA: AddisonWesley, 1994. [22] M. J. Ranum, "A network firewall." in Proc. World Conference on System Admin, and Security, July 1992. [23] M. Leech and M. Ganis, "SOCKS protocol version 5." RFC 1928, Bell-Northern Research, IBM, April 1996. [24] 0. S. Foundation, "DCE-the OSF distributed computing environment." in Proc. International DCE Workshop, 1993. [25] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: an authentication service for open network systems." in Proceedings of the Winter 1988 Usenix Conferences, (Dallas, Texas), pp. 191 201, February 1988. [26] J. Kohl and C. Neuman, "The Kerberos network authentication services {v5)." RFC 1510, Digital Equipment Corp., Sept. 1993. [27] ECMA, SESAME V3 Overview, June 1995. [28] D. Estrin, "Interconnection protocol for interorganization networks." IEEE J. Selected Areas Comm., vol. SAC-5, no. 9, pp. 1480-1491, 1987.

PAGE 143

134 [29] D. Estrin, J. Mogul, and G. Tsudik, "Visa protocols for controlling interorganizational datagram flow." IEEE Journal on Selected Areas in Communications, vol. 7, pp. 486-498, May 1989. [30] M. Iqbal and F. Poon, "Packet level access control scheme for internetwork security." lEE Proceedings1, vol. 139, pp. 165-175, April 1992. [31] R. M. Needham and M. D. Schroeder, "Using encryption for authentication in large network of computers." Communications of the ACM, vol. 21, pp. 993 999, December 1978. [32] D. E. Denning and G. M. Sacco, "Timestamps in key distribution protocols." Communications of the ACM, vol. 24, pp. 533 536, August 1981. [33] R. M. Needham and M. D. Schroeder, "Authentication revisited." Operating Systems Review, vol. 21, p. 7, January 1987. [34] D. Otway and 0. Rees, "Efficient and timely mutual authentication." Operating Systems Review, vol. 21, pp. 8 10, January 1987. [35] S. M. Bellovin and M. Merritt, "Limitations of the kerberos authentication system." in Proceedings of the Winter 1991 Usenix Conferences, (Dallas, Texas), pp. 1 15, February 1991. [36] A. Kehne, J. Schonwalder, and H. Langendorfer, "A nonce-based protocol for multiple authentication." Operating Systems Review, vol. 26, pp. 84 89, October 1992. [37] ITU-T, "Recommendation x.509: The directory-authentication framework." technical report, ITU-T, 1988. [38] T. Woo and S. Lam, "Authentication for distributed systems." IEEE Computer, pp. 39-40, January 1992. [39] T. Woo and S. Lam, "Authentication revisited." IEEE Computer, April 1992. [40] J. J. Tardo and K. Alagappan, "SPX: Global authentication using public key certificates." in Proceedings of IEEE Symposium on Security and Privacy, pp. 232244, 1991. [41] B. C. Neuman and S. G. Stubblebine, "A note on the use of timestamps as nonces." Operating Systems Review, vol. 27, pp. 10 14, April 1993. [42] M. Burrows, M. Abadi, and R. Needham, "A logic of authentication." Research Report 39, DEC SRC, February 1990. [43] B. Liskov, "Practical uses of synchronized clocks in distributed systems." in Proceedings of the tenth Annual ACM Symposium on Principles of Distributed Computing, pp. 1-9, August 1991.

PAGE 144

135 [44] L. Gong, "A security risk of depending on synchronized clocks." Operating Systems Review, vol. 26, pp. 49 53, January 1992. [45] J. T. Kohl, B. C. Neuman, and T. Y. Ts'o, "The evolution of the Kerberos authentication service." technical report, DEC, USC, MIT, 1991. [46] I.-L. Kao and R. Chow, "An efficient and secure authentication protocol using uncertified keys." technical report uf-cis-tr95-008, University of Florida, February 1995. [47] M. Burrows, M. Abadi, and R. Needham, "A logic of authentication: Appendix." Appendix to Research Report 39, DEC SRC, May 1994. [48] M. Steenstrup, "Inter-domain policy routing protocolspecification: version 1." RFC 1479, BBN Systems and Technologies, July 1993. [49] D. Clark, "Policy routing in internet protocols." RFC 1102, SRI Network Information Center, May 1989. [50] E. Rosen, "Exterior gateway protocol EGP." RFC 827, SRI Network Information Center, Oct. 1982. [51] D. Estrin, J. Mogul, G. Tsudik, and K. Anand, "Visa protocols for controlling inter-organizational datagram flow: Extended description." Technical Report, TR 88-50, University of Southern California, Computer Science Department, Dec. 1988. [52] P. Karger, "Authentication and discretionary control in computer networks." Computer Networks and ISDN Systems, vol. 10, no. 1, pp. 27-37, 1985. [53] D. M. Nessett, "Factors affecting distributed system security." in Proceedings of the IEEE Symposium on Security and Privacy, (Oakland, CA), pp. 204 222, May 1986. [54] D. Estrin and G. Tsudik, "End-to-end argument for network-layer access controls." TR 90-13, University of Southern Califonia, July 1990. [55] D. Estrin, "Policy requirements for inter administrative domain routing." RFC 1125, SRI Network Information Center, Dec. 1989. [56] W. Birnbaum, "SP3 peer identification." in Proceedings of IEEE Symposium on Security and Privacy, IEEE, May 1990. ;57] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)." RFC 1654, T.J. Watson Research Center, IBM Corp. Cisco Systems, July 1994. 58] K. Lougheed and Y. Rekhter, "A border gateway protocol 3 (BGP-3)." RFC 1267, Cisco Systems T.J. Watson Research Center, IBM Corp., Oct. 1991.

PAGE 145

136 [59] K. Lougheed and Y. Rekhter, "Border gateway protocol BGP." RFC 1105, Cisco Systems T.J. Watson Research Center, IBM Corp., June 1989. [60] H. Braun, "Models of policy routing." RFC 1104, SRI Network Information Center, June 1989. [61] H. Park and R. Chow, "Internetwork access control using public key certificates." in Proceedings of IFIP SEC '96 12th International Information Security Conference, pp. 237-246, May 1996. [62] R. Rivest, "The MD5 message-digest algorithm." RFC 1321, MIT, RSA, April 1992. [63] H. Park and R. Chow, "Enforcing inter-domain access control with ipv6." in Proceedings of 34th ACM Southeast Conference, pp. 192-197, April 1996. [64] L. Gong, "Variations on the themes of message freshness and replay." in Proc. IEEE Computer Security Foundations Workshop, June 1993. [65] B. Manning and R. Colella, "DNS NSAP resource records." RFC 1706, ISI, NIST, October 1994. [66] K. Lam and D. Gollmann, "Freshness assurance of authentication protocols." in Proceedings of ESORICS 92, SpringerVerlag, 1992. [67] R. Needham and M. Schroeder, "Using encryption for authentication in large networks of computers." Communications of the ACM, vol. 21, December 1978. [68] M. Abadi and R. Needham, "Prudent engineering practice for cryptographic protocols." Research Report 125, DEC SRC, June 1994. [69] R. Atkinson, "Security architecture for the internet protocol." RFC 1825, Naval Research Lab., Aug. 1995. [70] R. Atkinson, "IP authentication header." RFC 1826, Naval Research Lab., Aug. 1995. [71] R. Atkinson, "IP encapsulating security payload (ESP)." RFC 1827, Naval Research Lab., Aug. 1995. [72] C. A. Kent and J. C. Mogul, "Fragmentation considered harmful." Computer Communication Review, vol. 17, pp. 390-401, Aug. 1987. [73] G. Tsudik, "Datagram authentication in internet gateways: Implications of fragmentation and dynamic routing." IEEE Journal on Selected Areas in Communications, vol. 7, pp. 499-504, May 1989. [74] J. C. Mogul and S. E. Deering, "Path MTU discovery." RFC 1191, DEC Stanford, April 1990.

PAGE 146

137 [75] D. Maughan, M. Schertler, M. Schneider, and J. Turner, "Internet security association and key management protocol (ISAKMP)." internet-draft, NSA, June 1996. [76] S. Kent, "Privacy enhancement for internet electronic mail: Part II: Certificatebased key management." RFC 1422, BBN, Feb. 1993. [77] D. Eastlake and C. Kaufman, "Domain name system security extensions." internet draft, Cyberccish, Iris, Jan. 1996. [78] J. Linn, "Privacy enhancement for internet electronic mail: Part I: Message encryption and authentication procedures." RFC 1421, IETF PEM WG, Feb. 1993. [79] D. Balenson, "Privacy enhancement for internet electronic mail: Part III: Algorithms, modes, and identifiers." RFC 1423, TIS, Feb. 1993. [80] B. Kaliski, "Privacy enhancement for internet electronic mail: Part IV: Key certification and related services." RFC 1424, RSA Laboratories, Feb. 1993. [81] B. Schneier, Applied Cryptography. John Wiley and Sons, 2nd ed., 1996. [82] J. Linn, "Practical authentication for distributed computing." in Proc. IEEE Symp. Research in Security and Privacy., pp. 31-40, IEEE, 1990. [83] G. C. Inc., "Trusted facility manual for the gemini trusted guard base prototype." GTGB reference manual, Gemini Compuers Inc., Jan. 1996.

PAGE 147

BIOGRAPHICAL SKETCH Hyun Park was born on November 1, 1960, at KwangJu, Korea. He graduated from Seoul National University with a Bachelor of Science degree in instrumentation & control engineering in February 1983. After working in Gold Star Computer &; Communication Research Center for six years as a member of research staff and later as senior research staff, he started his graduate study in computer and information science and engineering at the University of Florida in August, 1989. He received his Doctor of Philosophy degree in August, 1996. 138