Celestial Security Management System

Chong Xu Fengmin Gong S. Felix Wu

Ilia Baldine Zhi Fu

Chandru Sargor He Huang

Frank Jou

Duke University MCNC North Carolina State University

[email protected] [email protected] [email protected]

Abstract tion by developing a security management architecture

that can 1 automatically discover e ective security

There has been a vast amount of research and devel-

p olicies and mechanisms along any network path, 2

opment e ort aimed at providing solutions and prod-

dynamically con gure security mechanisms across pro-

ucts that address the security needs in the information

to col layers and across the network, 3 adaptively re-

age. Each solution tends to address only a particu-

con gure these mechanisms to maintain certain levels

lar facet of the security problem and only accessible to

of security services when the network is under stress.

limitedprotocols or applications. Moreover, ad hoc de-

A prototyp e system referred to as Celestial has b een

ployment of some solutions e.g., rewal ls and IPsec

implemented to demonstrate the viability and use-

can hinder our ability to col laborate across networks.

fulness of this architecture. Main security mecha-

A very important question is how any application can

nisms integrated include a cryptographic library in

discover policy restrictions brought about by these so-

user space, IPsec, and ATM cell encryption. Key

lutions/mechanisms, and make ecient use of them to

comp onents of this system include the Security Man-

satisfy the application's security goals. The Celestial

agement Agent architecture SMA, a security service

project addresses this question by developing a secu-

API, and an inter-SMA communication proto col. The

rity management architecture that can 1 automat-

rest of the pap er is organized as follows. The remain-

ical ly discover e ective security policies and mecha-

der of this section intro duces the terminology that will

nisms along any network path, 2 dynamical ly con-

help in the following discussion and describ es the prob-

guresecurity mechanisms across protocol layers and

lem. Section 2 presents the Celestial architecture and

across the network, 3 adaptively re-con gure these

its main comp onents. Section 3 describ es the API.

mechanisms to maintain certain levels of security ser-

Section 4 presents the inter-SMA communication pro-

vices when the network is under stress. This paper

to col. Section 5 rep orts the implementation and the

describes the Celestial system design and implementa-

status of the system. In Section 6we review the re-

tion, and reports the current status of the project.

lated work in the area. We discuss the future work in

1 Intro duction

Section 7 and conclude the pap er with our thanks to

In spite of our serious concerns over the informa-

the reviwers.

tion security issues, secure networking is yet to be

1.1 Basic terminology

widely practiced. One reason is the lack of under-

Before discussing the security management problem

standing of security issues at a systematic level, e.g.,

and our solution to it, a brief intro duction of the terms

is security protection more imp ortant than qaulityof

we will b e using should b e helpful.

service QoS requirement and how to address b oth

security and the traditional QoS in the same service-

Secure communications are made p ossible through

provisioning framework? Furthermore, there is an

the use of security services, such as message con den-

overall lack of \secure information-ware", to ols for

tiality encryption, integrity, authenticity, and non-

navigating the information space securely and success-

repudiation. Security services are provided by secu-

fully. The Celestial pro ject is addressing this ques-

rity mechanisms that are software or hardware mo d-

ules by which security functions are implemented. For

This work is supp orted in part byDARPA/ITO through

instance, the Data Encryption Standard DES [1] [2]

Federal Contract DABT63-97-C-0045

Please send all corresp ondence to this author. is a security mechanism that provides a data encryp-

tion service. Security capability describ es a sp eci c

DOMAIN6 DOMAIN5

tation of a security mechanism. The net-

implemen HOST6 HOST5

work nodes refers to end-hosts, routers, and switches.

FIREWALL1 SWITCH2

A secure gateway is a router or a switch on which se-

curity p olicies are enforced and security mechanisms vided. are pro HOST1 SWITCH1 HOST4

ATM BACKBONE

y security mechanisms. We will only There are man IP BACKBONE EDGE-ROUTER1 SWITCH3

DOMAIN1 DOMAIN4

use IPsec [3, 3,5,?] and CellCase [4] throughout this

pap er to illustrate the heterogeneity of security mech-

FIREWALL2 EDGE-ROUTER2 anisms. * HOST1, HOST2, HOST4, HOST5 and HOST6 are IPsec-capable

* FIREWALL1 and FIREWALL2 are IPsec-capable

Problem description 1.2 * SWTCH1 and SWITCH2 are CellCase-capable HOST2 HOST3

DOMAIN2 DOMAIN3

Advances in network technology have greatly

changed the waywe share and exchange information

Figure 1: Heterogeneous network environment

and have b o omed many new online activities suchas

e-commerce. As the Internet gives rise to a new world

of global communication, more and more p eople are

applicable at the link layer. One disadvantage of

b ecoming concerned with the protection of their on-

link layer security mechanisms is that authentica-

line activities. Researchers have b een aware of the

tion, including signatures, can be provided only

lack of security in the communication network infras-

on a host basis. Furthermore, although message

tructure for years. For example, Internet Engineering

con dentiality can b e provided, message integrity

Task Force IETF has several working groups aimed

can b e more dicult to ensure if the link is byte-

at enhancing the security of network proto cols. In the

oriented, rather than frame-oriented.

meantime, industry has b een quick to catchupby de-

veloping many security pro ducts.

Network layer. Many researchers and engineers

Di erent e orts have led to di erent security solu-

argue that Internet Proto col IP layer is a go o d

tions, which means di erent security mechanisms can

place to enforce security b ecause all the pack-

b e used to provide the same security service and they

ets received by the lower-layer proto cols and all

can b e employed at di erent network proto col layers.

the packets sent from the higher-layer proto cols

Meanwhile, di erent organizations and individuals de-

and the applications go through it. The biggest

ne security di erently by enforcing di erent security

advantage of network layer security is its trans-

p olicies. Moreover, di erent network applications may

parency. It can be provided without requiring

havevarying security service requirements. All of this

changes to applications, any other higher layer

diversity results in a highly heterogeneous network en-

proto cols, or network comp onents that do not

vironment. Figure 1 is an illustration of suchanenvi-

need security functions. IPsec [3, 5,6] is the net-

ronment. The heterogeneity causes diculties in set-

work layer mechanism b eing standardized by the

ting up secure communication channels b ecause two

IETF.

communication end-p oints may not share common se-

curity mechanisms or the security p olicies for some

Transp ort layer. Providing security at the

no des on the path maybe violated. Let us examine

transp ort layer p ermits transp ort layer p eers to

the heterogeneity in closer detail.

communicate securely over insecure networks.

The ma jor advantage of providing security mech-

Security mechanisms can be applied at di er-

anisms at the transp ort layer, as opp osed to at

ent proto col layers. The TCP/IP proto col stack

the network layer, is that applications can p oten-

has four layers, i.e., data link layer, network layer,

tially cho ose di erent security mechanisms and

transp ort layer, and application layer. Network secu-

p olicies. The reason is that the transp ort layer

rity can b e enforced at any of these layers. Enforcing

typically keeps state that maps to individual ap-

security at di erentlayers has its advantages and dis-

plications. The primary drawback of transp ort

advantages.

layer security is that it is more dicult to enforce

Data link layer. Link layer security mechanisms a tunneling scheme and the rewall con guration.

can op erate at link sp eed, hence they put little Examples of transp ort layer security mechanisms

p erformance burden on the network no des. En- are Secure So cket Layer[7] and Transp ort Layer

cryption is the most common security mechanism Security Proto col[8].

con guration of security mechanisms will not b e able Application layer. Implementing security func-

to meet every application's requirement. tions directly at the application layer provides

the most exible way of handling the application-

sp eci c requirements. Advantages of providing

security functions at the application layer are that

Survivability over a public network. Talking

they are made available to all the applications,

ab out secure communications, we have to take into

and they can be selectively invoked by the ap-

account not only the two end-p oints of a communica-

plications when needed, thus limiting the p erfor-

tion, but also the condition of the path in which the

mance cost. However, the ability of the appli-

data packets travel. They b oth in uence what p olicies

cations to cho ose whether to utilize the security

are to b e enforced and what security mechanisms can

functions or not makes it harder to enforce the

b e used. For example, up on receiving security alarms

security p olicies.

due to a security breach, the p olicy of one domain

may require stronger encryption, e.g., a longer key,be

employed.

Diversity of security p olicies. The management

unit of the Internet is a domain, de ned by an au-

tonomous organization. Each organization has its own

From the ab ove discussion, we can see that static

p olicies which determine the usage of its resource and

con guration of available security mechanisms is im-

data. Security mechanisms employed by di erent or-

practical as an attempt to cover all the p ossible situ-

ganizations may di er due to their p olicies. Problems

ations of to day's heterogeneous network environment.

arise when organizations imp ort or exp ort data from

As a consequence, we need a powerful and exi-

one another, while requiring that data continue to b e

ble management infrastructure that can manage

protected in accordance with their p olicies. Currently,

di erent security mechanisms.

a rewall is the most widely employed mechanism that

enforces domain security p olicies.

So far, most of the research and engineering e orts

have b een fo cused on the individual security mecha-

nisms and proto cols. There have b een few attempts to

Variety of security capabilities. Di erent net-

address the managementof security mechanisms, let

work security solutions might not b e compatible with

alone managing the security mechanisms over di erent

each other b ecause they address security problems

proto col layers. Researchers from BBN prop osed Se-

in di erent ways. The Internet consists of hosts,

curityPolicy System [16] which tries to manage IPsec

routers and switches. Di erent network no des may

and its p olicies. Intel is building Common Data Secu-

be equipp ed with di erent security-related hardware

rity Architecture [17] that manages heterogeneous se-

and/or software, which lead to di erent security ca-

curity devices. To the b est of our knowledge, no other

pabilities. These security-related hardware/software

e ort has attempted to manage the security mech-

on one network no de can b e added or removed with-

anisms at di erent proto col layers and build a fully

out informing others. Moreover, problems arise when

distributed infrastructure capable of negotiating and

two end hosts that do not share the same security

dynamically setting up security communication chan-

capability try to communicate. For example, if one

nels.

domain signs data to preserve authenticity while the

Our research e ort is building a distributed secu-

other do es not have the algorithm to verify the signa-

rity management infrastructure that manages diverse

ture, the authenticity requirement needed in the com-

security mechanisms over di erent proto col layers for

munication between the two domains is simply not

the purp ose of secure communications. Our system is

p ossible.

capable of discovering the sp eci c mechanisms in com-

mon b etween domains as well as their p olicy require-

ments. It negotiates and dynamically sets up secure Di erent requirements from di erent applica-

communication channels utilizing these mechanisms. tions. Di erent applications have di erent security

The decision ab out the secure channel con guration, and service requirements. Some applications suchas

which may involve intermediate secure gateways, is video-conferencing software might need higher sp eed

made on-the- y based on the factors such as the do- of encryption while others such as email mayhaveno

main security p olicies, the security capabilities of the strict requirement on p erformance. On the contrary,

communication end-p oints, and the security and ser- the email software may need stronger encryption than

vice requirements of the application programs. the video-conferencing software. In this case, static

2 Prop osed Solution { Celestial Sys- top of TCP/UDP. We refer to them as the applica-

tions from now on. This means that secure versions of

tem

those higher layer proto cols b ene t from our system

We are developing a network security management

by utilizing existing security mechanisms underneath

technology { Celestial system, that addresses the se-

them.

cure communication dicultyintro duced by the het-

We will now use the network environmentin Fig-

erogeneity of the network securityenvironment. The

ure 1 to explain how the Celestial system works. An

key comp onent of our architecture is the Security

application on host1 wants to initiate a secure com-

Management Agent SMA, a set of software mo d-

munication with an application on host2. It conveys,

ules lo cated in network no des that have security re-

through an API, its intention to the SMA on host1,

quirements and/or provide security services. In order

along with the typ e of security service needed, say,

to utilize available security services, end-hosts need

con dentiality, and the requirements on the service

to install SMAs. Intermediate, esp ecially backb one,

quality. Up on receiving the request from the applica-

security gateways are not required to have SMAs in-

tion, the lo cal SMA generates a request message and

stalled. But we suggest that SMAs b e installed on the

sends it to the SMA on host2. The message is in-

switches or routers, esp ecially edge routers of a do-

tercepted by the SMAs on the data path of the com-

main, where the security p olicies need to b e enforced.

munication, i.e., edge Router1 and firewall2. They

The SMA is implemented as a mo dule residing outside

app end their own security capabilities along with sp e-

the op erating system kernel, thus requiring no kernel

cial security p olicy requirements and forward it. The

change to the systems for it to b e installed. Figure 2

security p olicies private to the lo cal domains are not

illustrates the deployment of SMAs over a network en-

app ended.

vironment.

When the SMA on host2 gets the request message,

it makes a decision on how the secure communication

channel should b e set up, based on its own p olicies and

the capability and requirement information carried by

Application Application

the request message. The decision includes which in-

ays will participate in setting

TCP/UDP TCP/UDP termediate secure gatew

the the secure communication and what security IP IP IP up

SMA SMA

hanisms will b e used b etween them. In this sp e- ATM ATM ATM mec

SMA

cial case, one plausible decision is as follows:

Link Link Link

Firewall2 has to participate b ecause it is a re-

End-host1 Router/Switch End-host2

wall;

Figure 2: Deployment of Security Management Agent

There will be an IPsec ESP tunnel between

over the Internet

host1 and firewall2;

2.1 Deployment of the Security Manage-

Host1 and host2 will use IPsec ESP to protect

ment Agent

data; 3DES will b e used as the encryption algo-

SMA resides logically on the management plane of

rithm.

the network infrastructure. It interacts with the se-

curity proto cols of eachlayer of the network proto col

The reason Firewall2 has to participate is deter-

stack and manages various management information

mined by the rewall p olicy requirement. In this case,

of the available security proto cols. It is authorized to

the application requests a con dentiality service with-

dynamically con gure lo cal security mechanisms of all

out a sp eci c requirement on the security proto col or

these proto cols. To establish a secure end-to-end com-

encryption algorithm. The SMA decides to use IPsec

munication, all the SMAs along the data path haveto

ESP and its default encryption algorithm, i.e., 3DES.

co ordinate in order to set up a securitychannel.

The decision is sent through the reverse path of the

incoming request. Up on receiving the decision, the In addition, an SMA has an interface to the ap-

intermediate SMAs check with their lo cal p olicies. If plication programs, through which di erent security

there is no p olicy con ict, the decision is forwarded services can be provided. Here the application pro-

towards host1. Then, the participating SMAs programs include the network application programs and

ceed to set up necessary security asso ciations, based other proto cols such as FTP, SMTP that reside on

on the decision, and exchange keys. After all the se- Security Service Mapping Mo dule is resp on-

curity mechanisms are successfully set up, the SMA sible for mapping the security service sp eci ca-

on host1 noti es the application and the application tions to lo cally available security mechanisms.

can start initializing handshake with the application

Security Service Con guration Mo dule is

on host2 and sending data.

the interface through which SMA manages and

Due to the uni-directional nature of IPsec security

invokes di erent security mechanisms.

asso ciations, the SMA on host2 will initiate the same

pro cedure by sending a request to the SMA on host1

Policy Enforcement Mo dule handles the se-

in order to set up the security channel for data to

curity p olicies. The p olicies de ne the protec-

travel from host2 to host1.

tion requirements for the current domain, for the

current lo cal network no de, for sp eci c proto cols,

2.2 Structure of the Security Manage-

and for sp eci c applications. Our current desgin

ment Agent

assumes that there exist a policy server in every

With the understanding of how the security man-

security domain where SMA is deployed. When a

agement agents are deployed, we now lo ok at what

p olicy server cho oses to delegate p olicy decisions

management functions an SMA provides as well as its

to individual SMAs in the domain, each SMA will

comp onents. Figure 3 shows the conceptual structure

make decisions by its own based on the p olicies

of a security management agent.

downloaded from the server; otherwise, the p ol-

icy mo dule will defer the p olicy decisions to its

server by forwarding the contact information for

Applications

the server to the destination SMA.

Cryptographic Application Layer

Sp ecial Service Interface allows us to take ad- Security Service API Library

SSL/TLS Transport Layer

antage of functionality of other infrastructures. SNMP MIB v IPsec

Security Service Configuration Network Layer

or example, we can use IPsec key exchange pro- IKE CellCase F Data Link Layer

Security Service Mapping Crypto Token

] so that we do not have to develop our LDAP to col [9] [10

IRS/CIDF

wn. Another example is that SMA can interface Policy Enforcement o Special Service Interface SMA Control Module

IDS/CIDF

with intrusion detection system. Up on receiving

Inter-SMA Communication Protocol

security alarms from an intrusion detection sys-

Security Magament Agent(SMA)

tem, SMA will start to enforce stronger security

Figure 3: Structure of Security Management Agent

p olicies and requirements for the later communi-

cations.

An SMA has eight mo dules, Security Service API,

Cryptographic Library is a library we pro-

Inter-SMA Communication Protocol ISCP, Service

vide to the application. It contains some basic

Mapping Module, Service Con guration Module, Pol-

security mechanisms, regardless of what security

icy Enforcement Module, Special Service Interface,

mechanisms may be provided in the underlying

Application-layer Cryptographic Library, and Control

networks. In the case where no other lo cal se-

Module.

curity mechanisms, e.g., IPsec, are available, or

no common security mechanisms are shared be-

Security Service API is an application pro-

tween two communication end-p oints in lower lay-

gramming interface that allows the applications

ers, our system can still supp ort end-to-end secure

to invokeavailable security mechanisms in order

communications by providing security services at

to receive security services. It is an extension to

the application layer. Moreover, an application

the BSD-so cket API, thus allowing existing net-

layer cryptographic library gives the applications

work applications to b e changed as little as p os-

the exibility of customizing security functions

sible in order to use our system. A more detailed

based on their own needs.

description of the API will b e given in Section 3.

Control Mo dule, aka the SMA Control ler, is

the heart of the SMA that glues other mo dules to- ISCP is a proto col used to provide communica-

tions b etween SMAs. ISCP itself is a secure and gether. It maintains a set of data structure, called

reliable proto col. A summary of ISCP is provided security contexts, each of which describ es a se-

in Section 4. cure communication channel setup:

study of this issue is outside the scop e of the current { who are the parties involved in the security

pro ject. service;

For all the SMAs, up on receiving the decision, their

{ which security mechanisms are used and in

Control lers extract their own assignments. If they

what combination;

need to participate, they check their lo cal Policy Mod-

{ the granularity at which a given security pro-

ule to see whether there is a con ict with the assign-

tection should b e applied;

ment or not. If the assignment is consistent with their

{ the algorithms used for encryption, integrity,

lo cal p olicies, the message is forwarded to the next

and authentication;

SMA on the reverse path.

If any intermediate no des, e.g., rewalls, are re-

{ the keys to the cryptographic algorithms.

quired to participate, they will start setting up secure

2.3 Interaction between di erent SMA

communication channels by con guring security mech-

mo dules

anisms through the Service Con guration Module, in-

The application makes a request for security ser-

cluding exchanging session keys through the Special

vices through Security Service API. Up on receiving

Service Interface. When the setup is done, i.e., the

this request, the Control ler rst checks, with the Pol-

security context is set up, the two applications can

icy Enforcement Module, to see whether the request is

start to communicate.

allowed by its lo cal p olicies. When getting a p ositive

3 Celestial Application Programming

answer, it gets the lo cal security capabilities from the

Interface

Service Mapping Module and sends them along with

We have extended BSD-so cket API as our Secu-

the request to the other communication end-p oint via

rity Service API. Currently the Security Service API

ISCP.

provides TCP supp ort while UDP supp ort is still in

The intermediate SMAs intercept the request.

development. The following table Table 1 compares

Their Control lers check with their own Policy Mod-

the TCP supp ort between the BSD-so cket API and

ules, get their lo cal capabilities from their own Service

the Celestial Security Service API.

Mapping Module, app end their capabilities and sp ecial

p olicy requirements to the message, and forward the

message towards the destination.

BSD-socket API Celestial Security Service API

When the destination SMA receives the request, its

socket sma socket

Control ler, co ordinating with its Policy Module and

bind sma bind

Service Mapping Module, makes a decision based on

connect sma connect

the information conveyed in the message and its own

listen sma listen

security p olicies and security capabilities. The deci-

accept sma accept

sion, in the form of security con guration assignments

to all the intermediate no des who need to participate read sma read

in order to provide an end-to-end secure communica-

write sma write

tion channel, is sent via ISCP along the reverse path.

close sma close

In general, the destination SMA may need to go

sma init

through several iterations b efore a con ict-free ser-

sma init sec context

vice con guration can be determined. The destina-

sma accept sec context

tion SMA accomplishes this by examining the p ol-

sma release sec context

icy requirements from those no des who have already

sma delete sec context

provided this information through the request packet,

formulating a con guration, and negotiating with the

p olicy servers for those domains that deferred p olicy

Table 1: TCP Supp ort in BSD-so cket API versus Ce-

decisions to their p olicy servers. Clearly, the desti-

lestial Security Service API

nation SMA mayhave to try several alternative con-

gurations b efore nding one that is con ict free, as- As shown in Table 1, the Celestial Security Service

suming that one do es exist. We should p oint out that API is similar to the BSD-so cket API. Sma socket,

there is a research issue regarding the general strategy sma read, sma write, etc, are wrapp ers to the

for determining service con gurations. This strategy original socket, read, write, etc. They are

should takeinto account factors such as security, p er- the same in terms of the syntax, and similar in terms

formance for data transfer, and setup time. In-depth of the semantics. The Celestial Security Service API

intro duces four more calls: sma init sec context, main unassigned by IANA.

sma accept sec context,

There are two sides to every ISCP communication:

sma release sec context,

the initiator and the resp onder. The initiator is the

and sma delete sec context, for the security con-

SMA-capable no de which desires to establish a secu-

text management. Sma init sec context and

rity asso ciation context with another SMA-capable

sma accept sec context are used to request for

no de the resp onder. SMA-capable no des that lie on

security services while sma release sec context

the path b etween the initiator and the resp onder are

and sma delete sec context release and delete

called intermediate no des.

security contexts resp ectively. Setting up a secu-

Each SMA-capable no de p ossesses various security

rity context can be very time-consuming. Thus,

mechanisms, which can b e used in the setup of a secu-

we want a security context to be reused if p ossible.

rity context. Examples of such mechanisms could b e

Sma release sec context releases a security con-

a IPSec or other secure tunnelling capability b SSL

text without deleting it, which gives us an opp ortu-

Secure So cket Layer c Encryption and Authentica-

nity to reuse the security context in the near future.

tion API library cryptlib and d ATM cell encryption

Security context reuse is very useful for applications

The decision ab out using particular security mech-

like the web client, b ecause the HTTP proto col uses

anisms and involving particular intermediate no des is

a TCP connection only once to fetch only one ob-

left to the resp onder. It makes these decisions based

ject le from the web server.

on the information it receives ab out the desired prop-

The way the application programs use our Security

erties of the security context supplied by the initia-

Service API is as follows. The client program rst

tor and the capabilities of the intermediate no des pro-

calls sma socket to create a so cket. Then it calls

vided by the SMAs lo cated in those no des. ISCP fa-

sma init sec context to request the security ser-

cilitates this information exchange and the delivery of

vice and asso ciate the created so cket with the secure

decisions.

context b eing set up. After the successful return of

ISCP was created to b e able to work with b oth IPv4

sma init sec context, the client program can use

and IPv6 address spaces. Since ISCP is considered to

the so cket in the same way as the BSD-so cket API.

b e a part of security infrastructure, rewalls must b e

That is to say, sma write and sma read are used

made aware of the ISCP proto col and allow it to pass

to send and receive data, except that data are sent and

through in order for the security contexts to be set

received in a secure fashion. After the data exchange,

up. Alhtough ISCP is built to supp ort discovery of

release sec context the client program calls sma

and negotiation among SMAs in the Celestial archi-

or sma delete sec context to release or delete the

tecture, the discovery and negotiation capabilities can

security context that was used. Then the client pro-

be applied to many other management issues in the

gram can call sma close to close the so cket. The

emerging networks. For example, rewalls in general

server program uses our Security Service API in a

can use ISCP for applications to discover their re-

similar way except that sma accept sec context

wall p olicies so that legitimate applications can tra-

is called instead of sma init sec context. In or-

verse the rewall legally and successfully, instead of

der to reuse a security context, the web client pro-

b eing blo cked blindly. To enable truly dynamic vir-

gram calls sma init sec context again. The lo cal

tual private network VPN services using IPSEC, all

SMA Control ler searches for a reusable security con-

we need to do is to deploy the Celestial system among

text that has not b een torn down. Up on nding one,

security gateways, with IPSEC as the only supp orted

it simply allows sma init sec context to return

security mechanism; existing applications can b e eas-

without sending out a request to trigger the negoti-

ily adapted to invoke the VPN service through Celes-

ation pro cess. This is transparent to the web client

tial API. We exp ect to be able to explore these op-

program.

p ortunities and extensions further through evaluation

exp eriments later in the pro ject.

4 Inter-SMA Communication Proto-

4.1 Message Overview

col

ISCP supp orts a number of messages in order to

ISCP proto col facilitates the setup and teardown of

facilitate its functionality:

security contexts between the SMAs. ISCP includes

several typ es of messages that are passed b etween the

SMAs. ISCP also includes several security features Path nding message: can b e sent by the initiator

that allow for encryption and authentication of ISCP to the resp onder, when it requires to set up a se-

messages. ISCP Proto col numb er is 137 122-254 re- curity context. This message is intended to be

intercepted by all SMA-capable no des that it tra- Bi-directional ow request: is sent by the initia-

verses. tor in order to sp eed up the connection setup

pro cess. ISCP asso ciations are uni-directional in

Path Refresh message: Similar in structure to the

nature b ecause actual IP routes for the two opp o-

Path nding message, this message is sentby the

site directions may di er. In order for two hosts

initiator p erio dically to the resp onder in order to

to have a bi-directional communication, they b oth

maintain the state of the security context in the

must setup contexts for each direction. The bi-

intermediate no des and prevent them from timing

directional ow request is sentby the initiator to

out.

the resp onder to inform it that it should initiate

a setup of its own.

Security Reservation message: can b e sentby the

resp onder to the initiator hop-by-hop through

Reservation acknowledgementACK RES:

the intermediate no des no interception required

the resp onder continues sending reservation mes-

with instructions to the intermediate no des to in-

sages until it receives the reservation acknowl-

voke approriate security services called assign-

edgement message from the initiator.

ments from now on in order to facilitate the setup

of a security context b etween the initiator and the

Figure 4 describ es the typical exchange between

resp onder.

SMA no des during context setup, lifetime and tear-

down. As can b e seen, some of the messages are in-

Reservation refresh message: is sent p erio dically

tercepted using the divert so cket functionality, while

by the resp onder in order to maintain the state

others are addressed and received directly by indended

of the security context.

no des.

Con rmation message: can b e sentby the resp on-

intermedeiate no des to the initiator

der and the InitiatorIntermediate Responder in order to con rm the completion of the setup of

PathFinding

their lo cal security mechanisms for a particular

y context.

securit Reservation

eardown message: can be sent by the

Initiator T Reservation Acknowledgement

to the resp onder in order to remove a

initiator Confirmation

y context. Also can b e

previously created securit Context Acknowledgement

sent as a reply to a Responder Teardown Message.

Context Establishment Acknowledgement of Acknowledgement

Resp onder Teardown message: can be sent by Lifetime Active Context

PathFinding Refresh

the resp onder to the initiator in order to removea

text. Also can b e sentinre-

previously created con Reservation Refresh

sp onse to the teardown request message from the

initiator in order to con rm the teardown. This

Initiator Teardown

message is sent hop-by-hop in order to remove the

Responder Teardown

context information from the intermediate no des.

Acknowledgement message ACK CTX: is

Context Teardown

sentby the initiator to the resp onder after all the

- denotes divert socket interception

exp ected con rmation messages have arrived.

Figure 4: ISCP message ow

ACK: AcknowledgementofACK ACK

is sentby the resp onder in order to con rm the

4.2 Security Considerations

receipt of the ACK message. This is the last mes-

As any other Internet Proto col, ISCP can b e sub-

sage in the initial exchange of messages b etween

ject to a number of attacks with the purp ose of dis-

the initiator and the resp onder which precedes

rupting its service or eavesdropping on the secure traf-

every security context setup.

Error message: intended to deliver error informa- ISCP takes sp ecial care in protecting the integrity

tion from the intermediate no des to the initiator. and authenticity of its messages. The header of each

ceiving them from ISCP and injecting them into the IP ISCP packet is authenticated and the payloads are en-

packet ow. The Linux divert so cket mechanism was crypted to preventeavesdropping. Separate keys are

implemented in our group and has b een made avail- used for the opp osite directions in communications to

able to the public www.anr.mcnc.org/ divert. further improve the security of the proto col. This pre-

The new prototyp e system includes the following vents a "man-in-the-middle" attack from succeeding.

functional comp onents: Even if a hacker has succeeded in intercepting and re-

formatting an ISCP message, trying to imp ersonate

Celestial security service API

an SMA-capable no de, he will not b e able to decrypt

the replies from the resp onder, as they will b e enco ded

ISCP version 2.0

with a separate key.

Two separate mechanisms are used for that pur-

SMA Control Module

p ose. Key distribution is done by using the Die-

Service Mapping Modules

Hellman algorithm run in phone-b o ok mo de with a

certi cate authority CA p ossessing the public p or-

Integrated cryptographic library cryptlib

tion of the no de's secret, which can b e distributed to

other no des on demand. In the absence of a CA,

Integrated IPsec and IKE capabilities based on

manual con guration can b e used for distributing the

FreeS/WAN 1.0

public comp onent of the key.

Three adapted applications: text-based web client

In order to encrypt and authenticate its messages,

and server, security-aware GUI web browser based

ISCP uses IDEA in CBC mo de, with the last 64-bit

on Arena and libwww, secure Internet audio and

cypher blo ck used as a signature for authentication.

intercepter programs.

ISCP will b e using 128-bit keys. Initially in the mes-

sage exchange the Die-Hellman keys are used. Dur-

ing the initial security context setup new session keys are distributed in order to b e used to decrypt and en-

APP Main Thread Policy DB crypt messages later during the session throughout the Controller

Context Table Decision lifetime of the context.

API Making

Implementation and Status

5 Context Table

rst prototyp e system was created based on The Comm Thread

Comm Thread ISCP

version 1.0 of the ISCP design. The system in-

the Listen Thread

cluded application level encryption RC4 and RC5

as the only security mechanisms. It supp orted b oth

FreeBSD and Solaris op erating systems. The system

Figure 5: Structure of Multi-Threaded Implementa-

was demonstrated to the DARPA program manager

tion

in Septemb er 1998 using text-based HTTP client and

server programs.

Note that the interaction between the application

As of this writing, we have completed the design

pro cess including the Celestial API invo cation and

and implementation of ISCP version 2.0. The soft-

the SMA daemon pro cess is achieved through a pair

ware structure for the implementation is shown in Fig-

of communication threads. The Policy currently al-

ure 5. The current implementation is supp orted under

lows anytyp e of communications by default. Wehave

b oth FreeBSD and Linux with divert-so cket enabled

examined several candidate technologies for adapta-

kernels. A Solaris end-host-only version utilizing raw

tion to provide p olicy resolution and distribution in

so ckets is also planned.

the Celestial system.

The divert so cket mechanism enables IP packet in- In the meantime, we will b e conducting exp eriments

terception and injection on the end-hosts as well as on on our testb ed to evaluate the p erformance and scal-

the routers. Both the interception and the injection ability asp ects of the system. Celestial architecture

happ en at the IP layer. The intercepted packets are allows security management agents to b e deployed in

diverted to so ckets in the user space. The intercepted an incremental fashion according to the security p oli-

packets can be reinjected into the IP packet ow by cies of an application domain. Every SMA-enabled

writing them to the so ckets. The divert so cket mecha- no de intro duces an access p oint for security service

nism supp orts ISCP op eration byintercepting incom- provisioning and p olicy enforcement. If more SMAs

ing ISCP packets and passing them to ISCP, then re- are deployed, it will allow more exibility in service

6.3 Intel's Common Data Security Archi- provisioning e.g.,multi-hop IPsec tunnels and multi-

tecture layer encryptions but also intro duces more latency

in end-to-end setup. Such trade-o s can b e explored

Common Data Security ArchitectureCDSA [17]

through exp eriments.

fo cuses on building a security infrastructure that

allows di erent vendors' security pro ducts to be

6 Related Work

plugged-in and utilized.

As we mentioned earlier, most of the researchwork

The key di erence b etween Celestial and CDSA is

so far has b een fo cused on individual security mech-

that Celestial manages security mechanisms and pro-

anisms. There have b een few e orts attempting to

vides security services from the p ersp ective of, but not

address the security managementover di erent proto-

limited to, the network proto col stack, while CDSA

col layers. We discuss the most relevant ones in the

treats security mechanisms more like devices. SMAs

next few paragraphs.

of Celestial system can not only negotiate and set up

6.1 Generic Security Service APIGSS-

communication channels that may require intermedi-

API

ate secure gateways to participate, but also recon g-

ure the security communication channels due to fac-

GSS-API [14] provides a generic interface for se-

tors like security p olicy changes, intrusion detection

curity services. It hides all the details of underlying

alarms, etc. CDSA, on the other hand, aims at end-

security mechanisms so that the user of GSS-API will

to-end communications and do es not have the notion

not havetoworry ab out the implementation of the se-

of a proto col stack and security gateways, thus secu-

curity mechanisms. GSS-API, together with a security

rity mechanisms such as smartcard that can b e treated

management system, can provide a similar functional-

as devices will t well into CDSA. It is not quite clear

ity to that of the Celestial system.

how CDSA would manage proto cols like IPsec.

Due to its generic nature, GSS-API is more useful

Furthermore, CDSA has a GSS-API-like security

in implementing higher layer security proto cols suchas

service API for \applications" to utilize the underlying

Kerb eros [15]. It is not tied to an easy-to-use network

security services, while Celestial's security service API

communication mechanism suchasthe BSD so ckets.

requires few changes in order for the applications to

Therefore, ordinary network applications will have dif-

adapt to the Celestial system b ecause it is an extension

culty adapting to it.

to the BSD-so cket API.

6.2 BBN's Security Policy System

6.4 Globus Pro ject

Researchers from BBN have prop osed a Security

Globus pro ject [18] aims at building basic software

Policy System [16]. In their system, there is a p olicy

infrastructure for computations that involve geograph-

server in each domain that controls all the security

ically distributed computational and information re-

p olicies and knows all the capabilities of lo cal network

sources. It implements its own security architecture,

no des. The p olicy servers are resp onsible for making

using GSS-API.

decisions on how to set up securitychannels.

The ma jor di erence b etween Celestial and Globus

There are di erences between the Policy System

is that they have di erent goals. Globus fo cuses on

and the Celestial system. First, Celestial is a fully

resource sharing, thus authentication and access con-

distributed system in terms of security management

trol are the key issues. In this case, GSS-API can

and decision making while Policy System is centralized

b e utilized to build its own authentication and access

within a domain. Second, for a p olicy server to know

control facility. From this p oint of view, the security

all the security p olicies and the security capabilities

services are used by Globus itself for its own needs.

within its domain is a very strong requirement. For

large domains with heterogeneous security capabilities

Celestial fo cuses on building infrastructure that

and p olicies for external connections, it may be nec-

provides exible utilization of the underlying secure

essary to deploy multiple p olicy servers for b oth the

network transp ort facilities. It manages all the secu-

security isolation and the p erformance reasons. Third,

rity proto cols and mechanisms that are used for se-

Policy System only manages IPsec p olicies, while Ce-

curity communications by the applications in a trans-

lestial fo cuses on the p olicy enforcement for all avail-

parent fashion.

able security mechanisms, not limited to IPsec. Celes-

7 Future work

tial decouples the p olicy enforcement from the p olicy

distribution/resolution. We are currently considering We exp ect to integrate an ATM level encryption

how BBN's Policy System can satisfy Celestial's p olicy capability and an intrusion detection system into the

distribution/resolution needs. Celestial management system. This will enable us to

Management Proto col." Internet Engineering Task further develop and demonstrate dynamic recon gu-

Force RFC2408, Novemb er 1998. ration of security services. Furthermore, we plan to

adapt more applications, such as a video conferenc-

[10] D. Harkins, D. Carrel, \The In-

ing program to use Celestial Security Service API. It

ternet Key Exchange." Internet Engineering Task

will b e interesting to adapt FTP and SMTP proto cols

Force RFC2409, Novemb er 1998.

from their insecure version by using Celestial Security

Service API. These will allowustoshow that applica-

[11] D. Pip er, \The Internet IP Security Domain of

tions with di erent security service requirements can

Interpretation for ISAKMP." Internet Engineering

utilize the underlying Security Service API as well as

Task Force RFC2407, Novemb er 1998.

the ability of Celestial system to dynamically con g-

[12] R. L. Rivest, \The RC4 Encryption Algorithm." ure the secure communication channels over an inse-

RSA Data Security, Inc., Mar 1992. cure wide-area public network.

8 Acknowledgments

[13] R. L. Rivest, \The RC5 Encryption Algorithm."

The reviewers provided very careful and construc-

Leuven Workshop on Algorithm'94. Available from

tive comments that help ed to improve the qualityof

URL http://theory.lcs.mit.edu/ rivest/rc5.ps.

this presentation. The authors wish to express their

[14] J. Linn, \Generic Security Service Application

gratitude for the reviewers' e ort.

Program Interface Version 2." Internet Engineering

References

Task Force RFC2078, January 1997.

[1] W.F. Ehrsam, C.H.W. Meyer, and R.L. Powers,

[15] S. P. Miller, C. Nermann, J. I. Schiller, and J.

J.K. Smith, and W.L. Tuchman, \Pro duct Blo ck

H. Saltze,

Cipher for Data Security." U.S. Patent 3,962,539,

\Kerb eros Authentication and Authorization sys-

8 Jun 1976.

tem." Pro ject Athena Technical Plan Section E.2.1,

[2] Bruce Schneier, \Applied Cryptography." Second

MIT, 1987. Available from URL http://athena-

Edition, John Wiley & Sons, Inc. 1996

dist.mit.edu/pub/kerb eros/do c/techplan.PS.

[16] L. A. Sanchez, M. N. Condell, \Secure Policy

[3] S. Kent, R. Atkinson, \Secure Architecture for In-

System." Internet Engineering Task Force Internet

ternet Proto col." Internet Engineering Task Force

Draft, Novemb er 18, 1998.

RFC2401, Novemb er 1998.

[17] Intel, Common

[4] D. Stevernson, N. Hillery, G. Byrd, F. Gong and D.

Data Security Architecture. Available from URL

Winkelstein, \Design of a Key Agile Cryptographic

http://develop er.intel.com/ial/security/index.htm.

System for OC-12c Rate ATM." Internet Society

Symposium on Network and Distributed Systems

[18] Globus Pro ject, Available from URL

Security, 1995.

http://www.globus.org/do cumentation/pap ers.html.

[5] S. Kent, R. Atkinson. \IP Authentication

HeaderAH." Internet Engineering Task Force

RFC2402, Novemb er 1998.

[6] S. Kent, R. Atkinson, \IP Encapsulating Security

PayloadESP." Internet Engineering Task Force

RFC2406, Novemb er 1998.

[7] Alan O. Freier, Philip Karlton, Paul C. Ko cher,

\The SSL Proto col Version 3.0." Available from:

http://home.netscap e.com/eng/ssl3/draft302.txt.

[8] T. Dierks, C. Allen, \The TLS proto col ver-

sion 1.0." January 1999. Available from URL

ftp://ftp.isi.edu/in-notes/rfc2246.txt.

[9] D. Maughan, M. Schertler, M. Schneider, J.

Turner, \Internet Security Asso ciation and Key