have Privacy-level DCE S c curit v Service su pport

O bjcctB rokcr provi

d

es no

p

rotect

i

on trom denial of service attacks either.

Dig;ir;1l Tccilniul )ottrnel! Vol . 9 0!o I 1 997 43

44

\\';1S nccessarv because there w:1s no concept of gloh:tl i dcmin· f(:>r �1 user, that is, ;l !l idenritv knom1 to :1 ! 1 computer nodes in a distri buted S\'Stc m.

To i mplemenr DCE Securin· on a p;1rricul;1r plat­

t(mll,

a Sccu rit\' Integration Architecture ;Kcomplishes the mapping of a globallv understood username ( e .g., a user or a security principal defined within ;1 DC

E

cel l or ro be pcd(mned. For the Open VMS svstcm, the glob;ll realm is the cluster. For the implementation of DCE i mplcrncntations of the

DCE.

For this reason, Object

B

rokcr retains �1 proxv mech­

a nism, n·cn for usc bv nodes that support the DCE.

identity mechanism, ObjectBroker's proxy i m plemen­

tation maps either a trusted remote user or a global Kcrbcros cncn·ption

,

ll'hicl1 is ;1 pril'ate or

symmetric

kev scheme ( as opposed to

a pu

blic or asymmetric kc\' scheme ) . A priv�1re kev scheme requires some trusted third-part\' node to ;lCt as a distribution center t(>r encryption kcvs or credentials. Each node or user has

;1

key that is known only to the user and the distribution uses three c:xdl<l llgcs �111d coJwersion kevs, results in :1

Pri,·ilcgcd Access Ccrtit( c;1 tc ( PAC:) in the possession ofa client. The PAC, 11·hich is appended to each request, contains the au thor i ;.�nion inf(>rmation to be com­

pared with the ;l

C

ccss comrol i n formation stored \\'ith the application server.

vVhen a c

l

ient wishes ro com municate with ^;1 sen'Cr, eac h must :�cq u i rc ;1 time-stamped session key t(Jr secure commu nic:ttio n . The session kev is protected in sever:tl wa\'S. The rime stamp means that the kev is similar to those given ro a user. These credentials al low the sen-cr to accept securit\' contexts from clients or to i n i tiate req u ests ( that is, become a client) to other secure commun icnion ,,·ith e:tch other.

Thus, if a server is configured

to

require authentica­ malicious software is not masquerading as a real server.

Note that the operations f()r acquiring credentials are accomplished outside the server executable. The operations arc pcrf<.Jrmed by the ObjectBroker run­

time software, based on con riguration setti ngs in the ObjcctBroker Secu rity Registry. The goal is to avoid burdening appl ications with the knowledge of security mechanisms.

Au thentication requirements can apply to the ObjcctBroker Agen t as wel l as to

c

lic

nr

s and servers.

Tht: Agent is in fact a separat<:: security principal, and one can require client-to-Agent, Agent-to-diem, Agent-to-server, and server-to-Agent authentication in an ObjectBrokcr configuration-in addition to authentication between the cl ient and the server. The client or the server can independently set these modes, or the ObjectBroker system can require that modes preserving u pward compatibility with prev1ous O bjectBroker versions. While compatibility is always a concern when u pgrading sofhvare, O bjectBroker's requirements in this area arc particu larly stringent because customers h ave mission-critical applications running i n very large confi gur a tions. In some cases, i t is difficult o r impossible t o u pgrade all O bject Broker nodes at one time, so it m ust be possi ble to do a rol ling u pgrade that minimizes the d istu rbance to the configuration and <llJows u

n

i

n

terrupted operatio n o f appli

c

ati

o

ns^.

The need fc>r dynamic, plug-in replaceability of the security su bsystem was an important issue for two reasons. first, to providt: standards- based solutions to computing problems, the ObjectBrokcr design had to allow the integration of any security product that implements the GSS-API . The second reason has to do with export controls.

United States government export regulations spccif)r that hardware, software, and documentation for cryp­

tographic products may be exported by license only.

Specifical ly, the Department of State's International Traffic in Arms Regulations

( 2 2

Code of Federal export restrictions. Therefore, Object Broker itself docs not i nclud<:: any cryptographic security mech,mism. An ObjectBroker customer must provide an appropriate GSS library; whatever package is available on the system is the one Object B roker wil l use.

ObjeetBroker Security Features

The security tearures that have been succcssndly imple­

mented in the ObjectBrokcr software i ncl ude

• Client-to-server, server-to-client, and mutual authentication

• Prot<::ction tl·om replay and sequencing attacks and imegrity protection

• Fine-grain control over the authentication m<::cha­

nism ( per-host, per-server, or per-method )

• Ability to demand a new securitv context for an invocation

• Ability to apply new secu rity featu res to applica­

tions without rebuilding them

• Dynamicallv l oadable security li braries

Usage

One of the most i mportant characteristics of a secure ORB is that appli cations ( clients and servers) need not be aware of security operations undertaken on th<::ir behalf. For ORBs, as well as for other support soft­

ware, the goal is to avoid burdening appl ications with the need to deal with the complexities of a d istributed system so that they can concentrate on the appl ication problem at hand .

Therefore, most of Object Broker's security-relevant operations are invisible to applications. ObjectBroker's management utilities are use

d

to specif)' the rules tor authenticating clients and servers. These rules are stored in the ObjcctBrokn Security R.egistrv, and the requirt:d authentications are performed automatically.

There are two exceptions to the general rule of keeping security operations invisible to the applica­

tion. The first is that a client or a server (when acting as a client) can explicitly mak<:: a call to an ObjectBroker API to toggle m utual authentication on or off. This operation is allowed as long as it docs not diminish the security level specified tor the ObjectBroker node as a whole. fn other words, a client can

d

eman

d

mutual authentjcation on a node that d oes nor require such authentication but cannot d isable murual au thentica ­ tion if the node does require it. This feature was imple­

mented to make i t possible tor clients to enabl e m u tual authentication for specific operations that have secu ­ rity releva nce .

Disiral Technical ^Journal Vol . 9 No. I 1 997 45

46

The second exception is th;lt J sen'Cr can demand the creJtion of a new securirv context �(>r ^{:1 11} i m·oct­

tion, which immediately rests the J u thenr i carion of the pri ncipal making t h e request. This is imponan t because the GSS-API allo\\'S the i nitiJtion o r' a securi tY co^ntext that has no exp^{i r}a^tion. Clcarlv, ^{i f} a sccu ritv context exists ^for a lon^{g enough} period , thc1'C ma\' be a concern that it is no longer valid. For example, when a user's Jccount is revoked ti-om the D C : l-� Security Registry, it is possible that the user's credentials Jrc still valid in some ^existing security context. Establishing a new security context forces

the

DCE run-rime sutiwarc to go back to the security server Jnd vcrit\· the v�1lidin·

of the principaL

Figu re

l

illustrates the i n teraction of ObjectBroku a mi the DCE Securit\• Sen·ice components in rhe esta b l ishment of a securin· context. Once the sccurin•

context is established, it is used i n the 1crification of MAC-sealed messages benveen the sen cr and the client. fn this i l l ustration, access to the DCE secu ritv subsystem is depicted as a local call, though JCccssing

these services

could also be done remorely.

The sequence of operati ons i n Figure l is as ti>llows:

l . A method invocation (a client request �(>r a remote operation) resu lts in a call to ObjectBroker's secu­

rin· subsystem.

2 . The ObjectRroker ^securitv s^u bwstem in turn i nvokes a GSS routine in the D C E Securin^· libran·.

This cal l determi nes whether ^J ne11· sccuri t\' con­

text needs to be established, ll"hich can happen for one of nvo reasons: either it i s the first invocation of this server from this client or the context rcti·esh rate has been specified as per-invocation.

3 . The DCE Secu rity library execu tes the cal l , which sets up the secu rity context. (Note that the p rocess of deleting an exis^ting securⁱty context is 110t shown . )

Figure 1 CLIENT

INVOCATION LAY ER

SECURI TY SUBSYS TEM

DCE SECURITY

FsLJblisb llJ.ent of a Secmir1· Comcxt

Digir�l TcchnicJ] Journc1l

TRANSP ORT

Vol ') No. 1 1 ')')7

4 . The secu rm· su bs1·srcm checks the retu rn status of the CSS routine

to

determine 11·h ether the resu l t­

ing token is ro be p�1ssed to ^the i m·ocation Ll\'er.

5, If so, the token is p�1ssed

to

the transport 1 �1\"Cr �(>r marsh:d ing.

6 . The cliem com1nunicarcs 11 i t h the sen·cr node through tile nomd O bjecrRroker channel.

7. T^he tr:msport layn i n the receiving node ^{u n mal·­}

shals the mc.<>s�1ge , oami nes the transport message h eader, and passes comrol ro a dispatcher

in

the in1·oc1tion l :tvcr,

8 . Dep^end ing on rhe mcss:tgc t1·pe, the message mav then be p�1ssed to �� special d ispatcher, in this Gl�e the secu rin· d isp�Hc hcr in the securin· su bsvstem .

9 . The sccuritl' su bsvstem determines that the mes­

sage should be hmdled lw the GSS implcmen ra­ rion and p�1sscs the mc�'agc thei'C.

1 0 . The D C : E Securit\' l ::wer checks the recci1·ed token and if it is ,.�l l i d , �lCcepts the sccuri^tl' contexr. The routine gcner�^tt^es ^a context establishment token

to be

passed to rhe

client.

The cal l also returns ^the server's conro r h�1 n d l c �(>r the sccurirv context the server shares ll"ith the c l i e nt .

1 1 . The secu rin· la1·n p�1sses the token to ^{the i m oc a ­} tion b\·er r<n lll�lrsld i ng.

1 2 . The i m ocnion ^b1·cr Jl1�1rsh<lls the i nh:mnation and se nds it as an :�q;umellt ro the ]o\\'- ln-cl tr�msport routine c:tl l.

1 3 . This mess�1ge is s c m ro tht client.

1 4 . The d:tta is u nm�1rsh,1kd,

1 5 . The message is sent to the security subsys^tem.

1 6 . The token is passed to rl1c GSS implementation to initialize the secmi rv con text, wi th the server­

supplied token :ts a n argument. The rou tine returns the cl ient's context h:mdle, IVhi c h is used ro sign subseq uem messages,

TRANSPORT

SERVER

INVOCATION LAYER

DCE SECURITY

Performance Considerations

The bcnctits of a secu re O R B arc not hcc . I f authenti ­ cation is required when a client and server establish a connection through a binding, part of that binding i m-olvcs the esta b l ishment or· a security context.

Establishment of �1 securitv context requ i res a rou n d ­ trip o n the network, d u ri n g which a token ti·om the client is passed to the scn·er, and a token is returned from the server to the c l ient in the mutual authentica­

tion case.

Once establ ished , the sccuritv context is used i n su bseq uent req u ests ( provided that the configuration does not req u i re sccu ritv context deletion a fter C\'ery method im·oc1tion ) . If tiK same sccuritv context is reused , the only additional overhead considerations arc (

1 )

the signing and ver i fication of req uests and responses i n the client and scncr, and ( 2 ) the sec uri tv context handle ( 32 additional bytes of i n tcm11ation ) appended to each message p<1Sscd between the client and the server.

The signing �md vcri ti cation of <1 signature on a request or response is d i frcrcnt ri·om the veritication of the p rivi leges used when the securi ty context is tirst set u p , i n rhat vcri tiCJtion of a signature docs not req uire a network round -tri p . In contrast, when you tirst set u p a sccuritv context, a network rou n d-trip to the privi lege server is req u i red, and its overhead is sign i ti ciil tly more costly than that of the vcritication and signatu re operations.

Note that when a client h::ts multiple object references to a single method impleme ntation in a server, a single sccuritv context ^em sti l l be used . For example, a derived object rctcrcncc docs not require J new sccurit\' con­

text. This is both an optimization and a functional requircmem, since onlv one sccuritv context is allowed between a client process and a scn·cr implementation.

Future Work

The Oi\!I C specifics a nu mber of object services in addi­

tion to the CORBA specification itself One of the most importanr specifications is t(x the C O REA Security Service. O bject Broker's i ntegration with D C E Security was designed and imp l emcmcd bdcxe the OMG's C:O RBA Sccu rit\1 Service specification was complete.

Thus, even though ObjcctBro kcr is the most secure OIU� available today, it is reasonable to ask when <1L1d how its secu rity rc.uurcs wi l l be made compliant with the latest specifications ti·om the OMG.

Given su fficient resou rces, ObjectBroker engineer­

ing could investigate supporting C:ORBA2 i nter­

operabi l i ty by implementi ng the OMG's General I nter- O RB Protocol ( C l OP ) . The G lOP architecture supports both the I nternet Inter-ORB Protocol ( ! l O P ) :md rhc D C L b:�scd Com mon I n ter-ORB Protocol

( DCE- C ! O P ) . Today, O bjcctBroker uses �1 wire proto­

col based on the CO RJ\A version 1 .2 spccitie1tion.

Security tor the I IOP is governed bv the Secure I nter­

O RB Protocol ( SE C I O P ) spcciticuion "', Jl though kw commercial ly avai lable implementations oft he S E C ! O P are available at the time of this writing. Also, �1s men­

tioned previouslv, sec uri tv fc>r the DCE-Cl 0 ! ' is accom p lished by protecting the RPC: connections �H the wire protocol b·e l . For the DCE _{RJ'C:, the DCE docs its} own authentication t(>r RPC: sessions; here the Rl'C:

connection bct\1·een the client <md the scn-cr, rather than the c lient and the scn-cr thcmschcs, is authcnr i ­ cated. This approach prm·idcs the same potcnrial tc>r securitv management in the O RB contiguration; it simply accompl ishes the sccurit\· fu nctions at a l evel i n the p rotocol stack that docs not req u i re the usc of the GSS-APL

Bv

b u i l d ing in support t(>r the C l O P, ObjectBrokcr gains the capabilit\1 to provide the secu ­ rity features fc)r both the J J O P a n d the DC:E-CJOP p rotocols in future releases.

The SECIOP and the D C E - C! O l' both t(>l low the u sage mode l of min i m i zing the need t()r applications to be aware of security. I n the S EC ! O l', the O M C has specitied APis tc)r security fu nctions, and these fu nctions are enti rely separ:�tc fro m any mechanism that implements them . O RB vendors will be ti-cc to provide securi ty rcaturcs in much tbc same way that ObjectBrok.cr provides security todav, i .e . , bv working from security-related i n tc>rmation kept bv the O RB . The SECIOP a l so provides tc>r administrati\·c objects and operations that perform sccurit\' m:1n�1gcmcnt functions lw means of A P i s .

Conclusion

Obj ectBroker prm·idcs statc-ofthc-<1rt d istri buted system securit\' todav. Its securit\' featu res prm·idc upward compati bil it\·, as well as the least possible dis­

tu rbance to existing O bjcctBrokcr applications ::tnd confi gurations. In add ition, ObjcctBrokcr's i m ple­

m entation of sccu rit\' bv 111C111S of the neE's Generic Securi tv Service Appl ication Programming I n terrace provides the greatest possible choice among sccurit\' mechanisms and sccurit\' implementation prm·iders.

References and Notes

1 . R. Otte,

P. Par.rick, and JV! . Rov, I

!uden'lrt udi

II,<.<

CONJJA (Upper Saddle River, N . )

. :

Prentice I-L l ! I ,

1 996).

2. Information ::tbout the Object Management Croup is available at http:/ /II'WW.Oill f!;.org.

3.

)

. Li n n , Generic Securi/ J ' Sen 'ice /ljJjJ!iutliun Pm­

gram

JnleljCtCI',

I nternet RFC 1 50R, ! 99 3 .

Digit::tl Tcchn.ic1l joumal \'ol. <) :-Jo ^{I I} '!97 47

-t. ). \Vr:11·, Generic .�<·curill Sen ·ice ,1 T'l Ocerl 'iell· ond C-IJindings. ^lnrcrncr RI-'C 1 :> 09, 1 99 3 .

::> . lntomlJtion <l bou r The Open G roup i s a,·,lii.Jblc ;l t

h ttp:/ /11 II II'.Opcngr<Hlp.org.

6. 1Y! . Gasser·, Buildin^.� o

S

ecu

re

^•

0Jmpu!er

SJ'Sicm

(Nell'

York, N . Y. : V.m Nostr;md Reinhol d , 1 9 8 8 ) . 7 . .\!Open DCf:> Aulhcn/ic({/fuu ({//(/ Securill' Scrciccs.

X/Open P rTi i m i n:m Spcciricltion P3 1 S , !SBJ\

l - 8 5 9 1 2 - 0 1 3 -X, c l cctror1ic 1 crsion ( Rc.1ding, U . K. :

X/Open Comp.1rw

Li mited, 1 9% ) .

8 . O!JwctBrok<'r- Ocsti!. llill,�

m!il

nu ildin,� Applico­

liuns. Part �o. Ar\ - (J X 1 LA-TK ( .\hq1;1rd , Mass . :

Digital Equiprncnr Corpor:ltion , 1 996 ) .

9 . S . Mille r, B � c u m a n ,

}.

Sch t l k r, :111d

J

S:1ltzcr, !\cr­

i?cms A uthe!llicctlirJII 01!(/ /\ui/.!orizotiun

.�l'Sicll!

(Ca

m

bridge, Mass . : M assaclw ,nrs Institute of Tech­

nologv, Project Athencl , 1 9 8 7 ) .

1 0 . CORDA Secu l'lty. Docurnem � u mber 9 5 - 1 2 - 0 1 ( }Lllll­

irlgham , Mass.: Object Man;1gcrncnr Group, l 9 9 S ) . The (),\·IG members 11 h o comributcd to the clocumellt ll'<::rc r\T&T Glob.ll l n r(mllc1ti ot1 Sol u tions Co., Digir.1l Equ i pment Corpor.ni on, r.�pcrsoli: Corporation,

(;roupe Bull, Hl'ldctt- Pxk.:ml CompJrll·, fnrenurional

B mi rH:ss M achi n

e

s Corpor;Hion ( i n coi!Jboration 11 irh Ta ligcnr Inc . ), I ntern :nioll:l l Computers Limited,

Nm ell I nc , Siemens Nixdorf 1 n t(mn<Hionssvsteme AC, Sunsofr I n c . , Tmdem Corn�1utcr l ncorpor.1tcd (in col­

l a bor·arion with Od l'sse1· Rcsc.1rch Associ<ltes Inc . ), and Ti1 oli S1·stems I nc .

Biographies

J

ohn

H.

Parodi

john Parodi is a consulting ^tcchn^ic·.ll IITitcr in ^the t'l'! ultipi:Hrorm Engineeri ng grout'· His priman· II'Ork

inq >ll'es u1stomcr conJ m u n ir.nions Jnd e,·,mgclism

t(>r object tcc hnologv. In e.1rlicr

ll'ork,

John pro1·idcd tn:hn ic:�l wri ting suppo^rt rc>1· the Compound Docu mcm Archi tectme group ;md Architcct m;JI Engineering ot'

S1·stcms :md Sofrii';Jr<: Teclmicd Office. Joh n joined J)J(;JT,\L in 1 9 79 <l ftcr 11 orki ng i n cornpu tcr operati

o

ns

;lt Hend ri x El ectronics ;lnd Jt the U ni1 nsm o f :\ c11·

H :1n1pshirc. He has rccci1 cd til o all':mls ri·om the Socict1 t(n Tec lmiul Comrn u n icuion :111d l1:1s more rlun 30 puhli­ cariorls 011 1·:1rious compu te r sc·ic·ncc ropic·>, incl u d i n g com­

pou nd douunenrs, object rcc·lmolog1·, corn1'utn sccurm·,

<llld !\ASIC Fred W. Burgher

Pri n c i t'JI engi neer fred R u rghcr is e m plol'cd bl' flEA Sl'stcms as a member ofthe Object Broker Engineering tc1 m . He is curren t!�' i nl'olvcd in O bjcctBrokcr ! l O P de·, _clopmcnt. Prc1·iouslv, h·ed 11 orked at D 1 G !TA l . on i nr egr·<lting DCE

Securitl'

:111d l\::1 r n i n g tc>r rhc Opcn\'MS Of1tTJtin� s1·sre m . Earlier in his c.1ren, he 11 .1s emploq:d Js :1 p^rincipa^{l en gi}neer at \V.

1

11g 1 .:1hor;1tories, 11 here he 11 orked i tl the lnugi ng EngitJCeri ng Croup. hcd stu d i ed compu ter science :n Roston l: n i 1 ersit1 .

DigiL>l Technical Jnun1.1l VoL 9 !'-:n 1 I \)<)7

A 1 60-M Hz, 32-b,

Im Dokument Digital Technical Journal (Seite 45-51)