Issue 7592: An extension of IOR to protect target objects Nature (corba-rtf) Source: (, ) Nature: Enhancement Severity: Summary: Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. +-------------+ +-------------+ | Client | Abstract IORs | Service | | application +-----------------++ Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | +---------------------------+ | | | BS2's IORs | | + +--------------+ | +------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server 1 | | Background | +------+-----+ +------------+ | Server 2 | | Background | +------------+ | Server 2 | +------------+ The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: AIOR = SP's regular IOR + logical name Logical name is uniquely corresponding to an IOR of an object running on background server. So the SP should set up the mapping before corresponding request comes, and map the logical name in the AIOR to the regular IOR of the target object at background server for a coming request. The structure of AIOR is compatible to regular IOR. Firstly let's have a look at the structure of regular IOR defined at page 13-15. Then we will discuss how to support AIOR based on existing IOR data structures and what interfaces and methods will be defined. module IOP { // IDL // Standard Protocol Profile tag values typedef unsigned long ProfileId; struct TaggedProfile { ProfileId tag; sequence <octet> profile_data; }; typedef sequence <TaggedProfile> TaggedProfileSeq ; // an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR { string type_id; sequence <TaggedProfile> profiles; }; // Standard way of representing multicomponent profiles. // This would be encapsulated in a TaggedProfile. typedef unsigned long ComponentId; struct TaggedComponent { ComponentId tag; sequence <octet> component_data; }; typedef sequence<TaggedComponent> TaggedComponentSeq; }; CORBA specification defines 3 standard IOR profiles (at page 13-17): module IOP { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef sequence <TaggedComponent> MultipleComponentProfile; }; The following are standard IOR components that can be included in TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, ESIOPs, or other protocols. An ORB must not drop these components from an existing IOR (at page 13-19). module IOP { const ComponentId TAG_ORB_TYPE = 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES = 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = 20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = 32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY = 37; const ComponentId TAG_INET_SEC_TRANS = 123; }; The following additional components that can be used by other protocols are specified in the DCE ESIOP chapter of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP section (at page 13-19, 13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The following is the description of our proposed supplement to CORBA core specification. We add one component into module IOP: const ComponentId TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The TAG_AIOR_LOGICALNAME component has an associated value of type string encoded as a CDR encapsulation. We have not defined the interface of mapping logical names to regular IOR because now this function is local and its interoperability is not necessary. But if two or more SPs want to exchange their mapping items to provide more intelegent services, we may need to define the coresponding interfaces. Resolution: Revised Text: Actions taken: July 15, 2004: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== m: webmaster@omg.org Date: 15 Jul 2004 05:09:25 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: jack_nudt Company: Computer Science Department, National University of Defence Technology mailFrom: jack_nudt@yahoo.com.cn Notification: Yes Specification: CommonObject Request Broker Architecture: Core Specification Section: Chp. 13 FormalNumber: formal Version: 3.0 RevisionDate: 02-11-03 Page: 13-17, 13-19 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2) Description Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. +-------------+ +-------------+ | Client | Abstract IORs | Service | | application +-----------------++ Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | +---------------------------+ | | | BS2's IORs | | + +--------------+ | +------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server 1 | | Background | +------+-----+ +------------+ | Server 2 | | Background | +------------+ | Server 2 | +------------+ The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: AIOR = SP's regular IOR + logical name Logical name is uniquely corresponding to an IOR of an object running on background server. So the SP should set up the mapping before corresponding request comes, and map the logical name in the AIOR to the regular IOR of the target object at background server for a coming request. The structure of AIOR is compatible to regular IOR. Firstly let's have a look at the structure of regular IOR defined at page 13-15. Then we will discuss how to support AIOR based on existing IOR data structures and what interfaces and methods will be defined. module IOP { // IDL // Standard Protocol Profile tag values typedef unsigned long ProfileId; struct TaggedProfile { ProfileId tag; sequence profile_data; }; typedef sequence TaggedProfileSeq ; // an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR { string type_id; sequence profiles; }; // Standard way of representing multicomponent profiles. // This would be encapsulated in a TaggedProfile. typedef unsigned long ComponentId; struct TaggedComponent { ComponentId tag; sequence component_data; }; typedef sequence TaggedComponentSeq; }; CORBA specification defines 3 standard IOR profiles (at page 13-17): module IOP { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef sequence MultipleComponentProfile; }; The following are standard IOR components that can be included in TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, ESIOPs, or other protocols. An ORB must not drop these components from an existing IOR (at page 13-19). module IOP { const ComponentId TAG_ORB_TYPE = 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES = 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = 20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = 32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY = 37; const ComponentId TAG_INET_SEC_TRANS = 123; }; The following additional components that can be used by other protocols are specified in the DCE ESIOP chapter of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP section (at page 13-19, 13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The following is the description of our proposed supplement to CORBA core specification. We add one component into module IOP: const ComponentId TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The TAG_AIOR_LOGICALNAME component has an associated value of type string encoded as a CDR encapsulation. We have not defined the interface of mapping logical names to regular IOR because now this function is local and its interoperability is not necessary. But if two or more SPs want to exchange their mapping items to provide more intelegent services, we may need to define the coresponding interfaces. X-Sender: andyp@ussfex01.bea.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 15 Jul 2004 08:20:53 -0700 To: Juergen Boldt , issues@omg.org, corba-rtf@omg.org From: Andy Piper Subject: Re: issue 7592 -- Core RTF issue? X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6GEgdlj018558 The scenario described is certainly one that almost all of our IIOP customers want addressed, and one that we have solved in various ways not covered by the core spec. However, I thought the firewall spec was specifically supposed to address these issues? andy At 07:41 AM 7/15/2004, Juergen Boldt wrote: From: webmaster@omg.org Date: 15 Jul 2004 05:09:25 -0400 To: Subject: Issue/Bug Report ---------- * Name: jack_nudt * Company: Computer Science Department, National University of Defence Technology * mailFrom: jack_nudt@yahoo.com.cn * Notification: Yes * Specification: CommonObject Request Broker Architecture: Core Specification * Section: Chp. 13 * FormalNumber: formal * Version: 3.0 * RevisionDate: 02-11-03 * Page: 13-17, 13-19 * Nature: Enhancement * Severity: Significant * HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2) Description Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. +-------------+ +-------------+ | Client | Abstract IORs | Service | | application +-----------------++ Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | +---------------------------+ | | | BS2's IORs | | + +--------------+ | +------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server 1 | | Background | +------+-----+ +------------+ | Server 2 | | Background | +------------+ | Server 2 | +------------+ The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: A.secafretni gnidnopseroc eht enifed ot deen yam ew ,secivres tnegeletni erom edivorp ot smeti gnippam rieht egnahcxe ot tnaw sPS erom ro owt fi tuB .yrassecen ton si ytilibareporetni sti dna lacol si noitcnuf siht won esuaceb ROI raluger ot seman lacigol gnippam fo ecafretni eht denifed ton evah eW .noitaluspacne RDC a sa dedocne gnirts epyt fo eulav detaicossa na sah tnenopmoc EMANLACIGOL_ROIA_GAT ehT .dItnenopmoC denimretednu na si XXX // ;XXX = EMANLACIGOL_ROIA_GAT dItnenopmoC tsnoc :POI eludom otni tnenopmoc eno dda eW .noitacificeps eroc ABROC ot tnemelppus desoporp ruo fo noitpircsed eht si gniwollof ehT ecivreS ytiruceS // ;301 = HCEM_CES_ECD_GAT dItnenopmoC tsnoc ;201 = SEPIP_ON_ECD_GAT dItnenopmoC tsnoc ;101 = EMAN_GNIDNIB_ECD_GAT dItnenopmoC tsnoc ;001 = GNIDNIB_GNIRTS_ECD_GAT dItnenopmoC tsnoc ;21 = YCILOP_NOITACOL_GAT dItnenopmoC tsnoc ;6 = NOITISOP_DI_TNIOPDNE_GAT dItnenopmoC tsnoc ;5 = YEK_TCEJBO_ETELPMOC_GAT dItnenopmoC tsnoc :)02-31 ,91-31 egap ta( noitces POISE ECD rof ecivreS ytiruceS eht ni ,ecivreS ytiruceS ,secivreSABROC dna tnemucod siht fo retpahc POISE ECD eht ni deificeps era slocotorp rehto yb desu eb nac taht stnenopmoc lanoitidda gniwollof ehT ;} ;321 = SNART_CES_TENI_GAT dItnenopmoC tsnoc ;73 = YCILOP_YTIVITCA_GAT dItnenopmoC tsnoc ;63 = SNART_CES_SLT_GAT dItnenopmoC tsnoc ;53 = SNART_CES_POICES_GAT dItnenopmoC tsnoc ;43 = GAT_LLUN_GAT dItnenopmoC tsnoc ;33 = TSIL_HCEM_CES_ISC_GAT dItnenopmoC tsnoc ;23 = YCILOP_VNI_GAT dItnenopmoC tsnoc ;13 = YCILOP_STO_GAT dItnenopmoC tsnoc ;03 = SRETUOR_EGASSEM_GAT dItnenopmoC tsnoc ;62 = YCILOP_NOITCASNART_GAT dItnenopmoC tsnoc ;52 = ESABEDOC_AVAJ_GAT dItnenopmoC tsnoc ;42 = OFNI_TCATNOC_PCCS_GAT dItnenopmoC tsnoc ;32 = SNART_LLAWERIF_GAT dItnenopmoC tsnoc ;22 = HCEM_CES_CIRENEG _GAT dItnenopmoC tsnoc ;12 = HCEM_CES_cilbuP_AMCE_ISC_GAT dItnenopmoC tsnoc ;02 = SNART_CES_LSS_GAT dItnenopmoC tsnoc ;91 = HCEM_CES_dirbyH_AMCE_ISC_GAT dItnenopmoC tsnoc ;81 = HCEM_CES_terceS_AMCE_ISC_GAT dItnenopmoC tsnoc ;71 = HCEM_CES_5VsorebreK_GAT dItnenopmoC tsnoc ;61 = HCEM_CES_2_MKPS_GAT dItnenopmoC tsnoc ;51 = HCEM_CES_1_MKPS_GAT dItnenopmoC tsnoc ;41 = EMAN_CES_GAT dItnenopmoC tsnoc ;31 = SNOITPO_NOITAICOSSA_GAT dItnenopmoC tsnoc ;3 = SSERDDA_POII_ETANRETLA_GAT dItnenopmoC tsnoc ;2 = SEICILOP_GAT dItnenopmoC tsnoc ;1 = STES_EDOC_GAT dItnenopmoC tsnoc ;0 = EPYT_BRO_GAT dItnenopmoC tsnoc { POI eludom .)91-31 egap ta( ROI gnitsixe na morf stnenopmoc eseht pord ton tsum BRO nA .slocotorp rehto ro ,sPOISE ,sPOIG rehto ,POII ot ylppa yam dna ,seliforp STNENOPMOC_ELPITLUM_GAT dna POI_TENRETNI_GAT ni dedulcni eb nac taht stnenopmoc ROI dradnats era gniwollof ehT ;} ;eliforPtnenopmoCelpitluM >tnenopmoCdeggaT< ecneuqes fedepyt ;2 = POI_PCCS_GAT dIeliforP tsnoc ;1 = STNENOPMOC_ELPITLUM_GAT dIeliforP tsnoc ;0 = POI_TENRETNI_GAT dIeliforP tsnoc { POI eludom :)71-31 egap ta( seliforp ROI dradnats 3 senifed noitacificeps ABROC ;} ;qeStnenopmoCdeggaT >tnenopmoCdeggaTtetco< ecneuqes ;gat dItnenopmoC { tnenopmoCdeggaT tcurts ;dItnenopmoC gnol dengisnu fedepyt .eliforPdeggaT a ni detaluspacne eb dluow sihT // .seliforp tnenopmocitlum gnitneserper fo yaw dradnatS // ;} ;seliforp >eliforPdeggaT< ecneuqes ;di_epyt gnirts { ROI tcurts .DI epyt a sulp ,seliforp locotorp cificeps-tcejbo // fo ecneuqes a si ecnerefeR tcejbO elbareporetnI na // ; qeSeliforPdeggaT >eliforPdeggaT< ecneuqes fedepyt ;} ;atad_eliforp >tetco< ecneuqes ;gat dIeliforP { eliforPdeggaT tcurts ;dIeliforP gnol dengisnu fedepyt seulav gat eliforP locotorP dradnatS // LDI // { POI eludom .denifed eb lliw sdohtem dna secafretni tahw dna serutcurts atad ROI gnitsixe no desab ROIA troppus ot woh ssucsid lliw ew nehT .51-31 egap ta denifed ROI raluger fo erutcurts eht ta kool a evah s'tel yltsriF .ROI raluger ot elbitapmoc si ROIA fo erutcurts ehT .tseuqer gnimoc a rof revres dnuorgkcab ta tcejbo tegrat eht fo ROI raluger eht ot ROIA eht ni eman lacigol eht pam dna ,semoc tseuqer gnidnopserroc erofeb gnippam eht pu tes dluohs PS eht oS .revres dnuorgkcab no gninnur tcejbo na fo ROI na ot gnidnopserroc yleuqinu si eman lacigoL eman lacigol + ROI raluger s'PS = ROI ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Subject: RE: issue 7592 -- Core RTF issue? Date: Fri, 16 Jul 2004 10:08:05 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7592 -- Core RTF issue? Thread-Index: AcRrQ9pQLp6ubTMmSFSp+LbrZPjQhQADlC40 From: "Ke Jin" To: "Andy Piper" , "Juergen Boldt" , , X-OriginalArrivalTime: 16 Jul 2004 17:08:05.0524 (UTC) FILETIME=[75C2BD40:01C46B57] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i6GHIFlj021313 Hasn't this issue already been addressed by OMG firewall spec., in either NAT or proxy scenario? In NAT scenario, ORB implementations can simply put NAT translated address and port number in IIOP profiles. most ORBs support this already. In proxy scenario, ORB, in combining with a proxy, can put a facked IP, port in IIOP profile, and proxy's address (IP and port ) in firewall component of the same profile. The object key in the IOR is simply a mapping to the real IP:port:key only known by the proxy. Then, client can only access the object through the proxy address. Also, even if above mechanisms weren't sufficient, I would prefer a new component or even a new profile based solution, rather than a new AIOR. Otherwise, we might have a number of other specs (such as BiDir-IIOP, firewall, etc.) to be changed in consisting with this new AIOR. Just my 2cents Ke -----Original Message----- From: Andy Piper [mailto:andyp@bea.com] Sent: Thu 7/15/2004 8:20 AM To: Juergen Boldt; issues@omg.org; corba-rtf@omg.org Cc: Subject: Re: issue 7592 -- Core RTF issue? The scenario described is certainly one that almost all of our IIOP customers want addressed, and one that we have solved in various ways not covered by the core spec. However, I thought the firewall spec was specifically supposed to address these issues? andy At 07:41 AM 7/15/2004, Juergen Boldt wrote: >>From: webmaster@omg.org >>Date: 15 Jul 2004 05:09:25 -0400 >>To: >>Subject: Issue/Bug Report >> >> >>---------- >> * Name: jack_nudt >> * Company: Computer Science Department, National University of >> Defence Technology >> * mailFrom: jack_nudt@yahoo.com.cn >> * Notification: Yes >> * Specification: CommonObject Request Broker Architecture: Core >> Specification >> * Section: Chp. 13 >> * FormalNumber: formal >> * Version: 3.0 >> * RevisionDate: 02-11-03 >> * Page: 13-17, 13-19 >> * Nature: Enhancement >> * Severity: Significant >> * HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; >> MyIE2) >> >> >> >>Description >> >> >> >> >> >>Related Specification: CommonObject Request Broker Architecture: Core >>Specification November 2002 Version 3.0 - Editorial edit to cover >>formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect >>target objects Nature: Enhancement Issue Summary: IOR (Interoperable >>Object Reference) is the distributed reference of a CORBA object. The IOR >>of a target object is distributed to client applications that want to >>access the target object. Clients can easily connect to the target >>objects based on the location information in IOR. As a kind of object >>discovery scheme, IOR publishes some attributes related to target object, >>such as IP address, port number, internal object id, etc. As we know, >>many kinds of attacks can be performed to a target server when the IP >>address and port number of the target is exposed. The exposition of >>internal object id may also leads to security problems. We use Abstract >>IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent >>to client applications, thus the target objects is protected from >>potential attacks. Proposed solution: We use proxy technology to protect >>target servers, following is the architecture of a typical scenario. >>Service Proxy (SP) acts as a portal for all background servers. SP will >>handle all requests from clients to background servers. So background >>servers are transparent to clients. +-------------+ +-------------+ | >>Client | Abstract IORs | Service | | application +-----------------++ >>Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | >>+---------------------------+ | | | BS2's IORs | | + +--------------+ | >>+------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server >>1 | | Background | +------+-----+ +------------+ | Server 2 | | >>Background | +------------+ | Server 2 | +------------+ The core concept >>of the above architecture is Abstract IOR (AIOR). AIOR can be described >>by a simple equation: AIOR = SP's regular IOR + logical name Logical name >>is uniquely corresponding to an IOR of an object running on background >>server. So the SP should set up the mapping before corresponding request >>comes, and map the logical name in the AIOR to the regular IOR of the >>target object at background server for a coming request. The structure of >>AIOR is compatible to regular IOR. Firstly let's have a look at the >>structure of regular IOR defined at page 13-15. Then we will discuss how >>to support AIOR based on existing IOR data structures and what interfaces >>and methods will be defined. module IOP { // IDL // Standard Protocol >>Profile tag values typedef unsigned long ProfileId; struct TaggedProfile >>{ ProfileId tag; sequence profile_data; }; typedef sequence >> TaggedProfileSeq ; // an Interoperable Object Reference >>is a sequence of // object-specific protocol profiles, plus a type ID. >>struct IOR { string type_id; sequence profiles; }; // >>Standard way of representing multicomponent profiles. // This would be >>encapsulated in a TaggedProfile. typedef unsigned long ComponentId; >>struct TaggedComponent { ComponentId tag; sequence >>component_data; }; typedef sequence TaggedComponentSeq; >>}; CORBA specification defines 3 standard IOR profiles (at page 13-17): >>module IOP { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId >>TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef >>sequence MultipleComponentProfile; }; The following are >>standard IOR components that can be included in TAG_INTERNET_IOP and >>TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, >>ESIOPs, or other protocols. An ORB must not drop these components from an >>existing IOR (at page 13-19). module IOP { const ComponentId TAG_ORB_TYPE >>= 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES >>= 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId >>TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const >>ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId >>TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; >>const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId >>TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = >>20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const >>ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId >>TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; >>const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId >>TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; >>const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = >>32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId >>TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const >>ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY >>= 37; const ComponentId TAG_INET_SEC_TRANS = 123; }; The following >>additional components that can be used by other protocols are specified >>in the DCE ESIOP chapter of this document and CORBAServices, Security >>Service, in the Security Service for DCE ESIOP section (at page 13-19, >>13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId >>TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; >>const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId >>TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; >>const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The >>following is the description of our proposed supplement to CORBA core >>specification. We add one component into module IOP: const ComponentId >>TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The >>TAG_AIOR_LOGICALNAME component has an associated value of type string >>encoded as a CDR encapsulation. We have not defined the interface of >>mapping logical names to regular IOR because now this function is local >>and its interoperability is not necessary. But if two or more SPs want to >>exchange their mapping items to provide more intelegent services, we may >>need to define the coresponding interfaces. > > >================================= >Jürgen Boldt >Director, Member Services > >Object Management Group >250 First Avenue, Suite 100 >Needham, MA 02494 > >Tel. +1 781 444 0404 ext. 132 >Fax: +1 781 444 0320 >email: juergen@omg.org >www www.omg.org > >================================ Subject: RE: issue 7592 -- Core RTF issue? Date: Fri, 16 Jul 2004 10:15:04 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7592 -- Core RTF issue? Thread-Index: AcRrQ9pQLp6ubTMmSFSp+LbrZPjQhQADlC40AAF8seE= From: "Ke Jin" To: "Andy Piper" , "Juergen Boldt" , , X-OriginalArrivalTime: 16 Jul 2004 17:15:04.0700 (UTC) FILETIME=[6F9BEBC0:01C46B58] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i6GHPYlj021505 My reply can be igored. Andy basically said the same thing. I only readed the original issue attached in Andy's message, but not Andy's response itself. Ke -----Original Message----- From: Ke Jin Sent: Fri 7/16/2004 10:08 AM To: Andy Piper; Juergen Boldt; issues@omg.org; corba-rtf@omg.org Cc: Subject: RE: issue 7592 -- Core RTF issue? Hasn't this issue already been addressed by OMG firewall spec., in either NAT or proxy scenario? In NAT scenario, ORB implementations can simply put NAT translated address and port number in IIOP profiles. most ORBs support this already. In proxy scenario, ORB, in combining with a proxy, can put a facked IP, port in IIOP profile, and proxy's address (IP and port ) in firewall component of the same profile. The object key in the IOR is simply a mapping to the real IP:port:key only known by the proxy. Then, client can only access the object through the proxy address. Also, even if above mechanisms weren't sufficient, I would prefer a new component or even a new profile based solution, rather than a new AIOR. Otherwise, we might have a number of other specs (such as BiDir-IIOP, firewall, etc.) to be changed in consisting with this new AIOR. Just my 2cents Ke -----Original Message----- From: Andy Piper [mailto:andyp@bea.com] Sent: Thu 7/15/2004 8:20 AM To: Juergen Boldt; issues@omg.org; corba-rtf@omg.org Cc: Subject: Re: issue 7592 -- Core RTF issue? The scenario described is certainly one that almost all of our IIOP customers want addressed, and one that we have solved in various ways not covered by the core spec. However, I thought the firewall spec was specifically supposed to address these issues? andy At 07:41 AM 7/15/2004, Juergen Boldt wrote: >>From: webmaster@omg.org >>Date: 15 Jul 2004 05:09:25 -0400 >>To: >>Subject: Issue/Bug Report >> >> >>---------- >> * Name: jack_nudt >> * Company: Computer Science Department, National University of >> Defence Technology >> * mailFrom: jack_nudt@yahoo.com.cn >> * Notification: Yes >> * Specification: CommonObject Request Broker Architecture: Core >> Specification >> * Section: Chp. 13 >> * FormalNumber: formal >> * Version: 3.0 >> * RevisionDate: 02-11-03 >> * Page: 13-17, 13-19 >> * Nature: Enhancement >> * Severity: Significant >> * HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; >> MyIE2) >> >> >> >>Description >> >> >> >> >> >>Related Specification: CommonObject Request Broker Architecture: Core >>Specification November 2002 Version 3.0 - Editorial edit to cover >>formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect >>target objects Nature: Enhancement Issue Summary: IOR (Interoperable >>Object Reference) is the distributed reference of a CORBA object. The IOR >>of a target object is distributed to client applications that want to >>access the target object. Clients can easily connect to the target >>objects based on the location information in IOR. As a kind of object >>discovery scheme, IOR publishes some attributes related to target object, >>such as IP address, port number, internal object id, etc. As we know, >>many kinds of attacks can be performed to a target server when the IP >>address and port number of the target is exposed. The exposition of >>internal object id may also leads to security problems. We use Abstract >>IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent >>to client applications, thus the target objects is protected from >>potential attacks. Proposed solution: We use proxy technology to protect >>target servers, following is the architecture of a typical scenario. >>Service Proxy (SP) acts as a portal for all background servers. SP will >>handle all requests from clients to background servers. So background >>servers are transparent to clients. +-------------+ +-------------+ | >>Client | Abstract IORs | Service | | application +-----------------++ >>Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | >>+---------------------------+ | | | BS2's IORs | | + +--------------+ | >>+------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server >>1 | | Background | +------+-----+ +------------+ | Server 2 | | >>Background | +------------+ | Server 2 | +------------+ The core concept >>of the above architecture is Abstract IOR (AIOR). AIOR can be described >>by a simple equation: AIOR = SP's regular IOR + logical name Logical name >>is uniquely corresponding to an IOR of an object running on background >>server. So the SP should set up the mapping before corresponding request >>comes, and map the logical name in the AIOR to the regular IOR of the >>target object at background server for a coming request. The structure of >>AIOR is compatible to regular IOR. Firstly let's have a look at the >>structure of regular IOR defined at page 13-15. Then we will discuss how >>to support AIOR based on existing IOR data structures and what interfaces >>and methods will be defined. module IOP { // IDL // Standard Protocol >>Profile tag values typedef unsigned long ProfileId; struct TaggedProfile >>{ ProfileId tag; sequence profile_data; }; typedef sequence >> TaggedProfileSeq ; // an Interoperable Object Reference >>is a sequence of // object-specific protocol profiles, plus a type ID. >>struct IOR { string type_id; sequence profiles; }; // >>Standard way of representing multicomponent profiles. // This would be >>encapsulated in a TaggedProfile. typedef unsigned long ComponentId; >>struct TaggedComponent { ComponentId tag; sequence >>component_data; }; typedef sequence TaggedComponentSeq; >>}; CORBA specification defines 3 standard IOR profiles (at page 13-17): >>module IOP { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId >>TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef >>sequence MultipleComponentProfile; }; The following are >>standard IOR components that can be included in TAG_INTERNET_IOP and >>TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, >>ESIOPs, or other protocols. An ORB must not drop these components from an >>existing IOR (at page 13-19). module IOP { const ComponentId TAG_ORB_TYPE >>= 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES >>= 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId >>TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const >>ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId >>TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; >>const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId >>TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = >>20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const >>ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId >>TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; >>const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId >>TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; >>const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = >>32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId >>TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const >>ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY >>= 37; const ComponentId TAG_INET_SEC_TRANS = 123; }; The following >>additional components that can be used by other protocols are specified >>in the DCE ESIOP chapter of this document and CORBAServices, Security >>Service, in the Security Service for DCE ESIOP section (at page 13-19, >>13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId >>TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; >>const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId >>TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; >>const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The >>following is the description of our proposed supplement to CORBA core >>specification. We add one component into module IOP: const ComponentId >>TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The >>TAG_AIOR_LOGICALNAME component has an associated value of type string >>encoded as a CDR encapsulation. We have not defined the interface of >>mapping logical names to regular IOR because now this function is local >>and its interoperability is not necessary. But if two or more SPs want to >>exchange their mapping items to provide more intelegent services, we may >>need to define the coresponding interfaces. > > >================================= >Jürgen Boldt >Director, Member Services > >Object Management Group >250 First Avenue, Suite 100 >Needham, MA 02494 > >Tel. +1 781 444 0404 ext. 132 >Fax: +1 781 444 0320 >email: juergen@omg.org >www www.omg.org > >================================ X-Sender: juergen@amethyst.omg.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 16 Jul 2004 14:06:22 -0400 To: "Ke Jin" From: Juergen Boldt Subject: RE: issue 7592 -- Core RTF issue? Cc: "Andy Piper" , , Ke, Andy, Isn't the Firewall spec a dead fish in the water? The FTF report has not been adopted, so the spec is currently not finalized.. -Juergen At 01:15 PM 7/16/2004, Ke Jin wrote: My reply can be igored. Andy basically said the same thing. I only readed the original issue attached in Andy's message, but not Andy's response itself. Ke -----Original Message----- From: Ke Jin Sent: Fri 7/16/2004 10:08 AM To: Andy Piper; Juergen Boldt; issues@omg.org; corba-rtf@omg.org Cc: Subject: RE: issue 7592 -- Core RTF issue? Hasn't this issue already been addressed by OMG firewall spec., in either NAT or proxy scenario? In NAT scenario, ORB implementations can simply put NAT translated address and port number in IIOP profiles. most ORBs support this already. In proxy scenario, ORB, in combining with a proxy, can put a facked IP, port in IIOP profile, and proxy's address (IP and port ) in firewall component of the same profile. The object key in the IOR is simply a mapping to the real IP:port:key only known by the proxy. Then, client can only access the object through the proxy address. Also, even if above mechanisms weren't sufficient, I would prefer a new component or even a new profile based solution, rather than a new AIOR. Otherwise, we might have a number of other specs (such as BiDir-IIOP, firewall, etc.) to be changed in consisting with this new AIOR. Just my 2cents Ke -----Original Message----- From: Andy Piper [mailto:andyp@bea.com] Sent: Thu 7/15/2004 8:20 AM To: Juergen Boldt; issues@omg.org; corba-rtf@omg.org Cc: Subject: Re: issue 7592 -- Core RTF issue? The scenario described is certainly one that almost all of our IIOP customers want addressed, and one that we have solved in various ways not covered by the core spec. However, I thought the firewall spec was specifically supposed to address these issues? andy At 07:41 AM 7/15/2004, Juergen Boldt wrote: >>From: webmaster@omg.org >>Date: 15 Jul 2004 05:09:25 -0400 >>To: >>Subject: Issue/Bug Report >> >> >>---------- >> * Name: jack_nudt >> * Company: Computer Science Department, National University of >> Defence Technology >> * mailFrom: jack_nudt@yahoo.com.cn >> * Notification: Yes >> * Specification: CommonObject Request Broker Architecture: Core >> Specification >> * Section: Chp. 13 >> * FormalNumber: formal >> * Version: 3.0 >> * RevisionDate: 02-11-03 >> * Page: 13-17, 13-19 >> * Nature: Enhancement >> * Severity: Significant >> * HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; >> MyIE2) >> >> >> >>Description >> >> >> >> >> >>Related Specification: CommonObject Request Broker Architecture: Core >>Specification November 2002 Version 3.0 - Editorial edit to cover >>formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect >>target objects Nature: Enhancement Issue Summary: IOR (Interoperable >>Object Reference) is the distributed reference of a CORBA object. The IOR >>of a target object is distributed to client applications that want to >>access the target object. Clients can easily connect to the target >>objects based on the location information in IOR. As a kind of object >>discovery scheme, IOR publishes some attributes related to target object, >>such as IP address, port number, internal object id, etc. As we know, >>many kinds of attacks can be performed to a target server when the IP >>address and port number of the target is exposed. The exposition of >>internal object id may also leads to security problems. We use Abstract >>IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent >>to client applications, thus the target objects is protected from >>potential attacks. Proposed solution: We use proxy technology to protect >>target servers, following is the architecture of a typical scenario. >>Service Proxy (SP) acts as a portal for all background servers. SP will >>handle all requests from clients to background servers. So background >>servers are transparent to clients. +-------------+ +-------------+ | >>Client | Abstract IORs | Service | | application +-----------------++ >>Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | >>+---------------------------+ | | | BS2's IORs | | + +--------------+ | >>+------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server >>1 | | Background | +------+-----+ +------------+ | Server 2 | | >>Background | +------------+ | Server 2 | +------------+ The core concept >>of the above architecture is Abstract IOR (AIOR). AIOR can be described >>by a simple equation: AIOR = SP's regular IOR + logical name Logical name >>is uniquely corresponding to an IOR of an object running on background >>server. So the SP should set up the mapping before corresponding request >>comes, and map the logical name in the AIOR to the regular IOR of the >>target object at background server for a coming request. The structure of >>AIOR is compatible to regular IOR. Firstly let's have a look at the >>structure of regular IOR defined at page 13-15. Then we will discuss how >>to support AIOR based on existing IOR data structures and what interfaces >>and methods will be defined. module IOP { // IDL // Standard Protocol >>Profile tag values typedef unsigned long ProfileId; struct TaggedProfile >>{ ProfileId tag; sequence profile_data; }; typedef sequence >> TaggedProfileSeq ; // an Interoperable Object Reference >>is a sequence of // object-specific protocol profiles, plus a type ID. >>struct IOR { string type_id; sequence profiles; }; // >>Standard way of representing multicomponent profiles. // This would be >>encapsulated in a TaggedProfile. typedef unsigned long ComponentId; >>struct TaggedComponent { ComponentId tag; sequence >>component_data; }; typedef sequence TaggedComponentSeq; >>}; CORBA specification defines 3 standard IOR profiles (at page 13-17): >>module IOP { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId >>TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef >>sequence MultipleComponentProfile; }; The following are >>standard IOR components that can be included in TAG_INTERNET_IOP and >>TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, >>ESIOPs, or other protocols. An ORB must not drop these components from an >>existing IOR (at page 13-19). module IOP { const ComponentId TAG_ORB_TYPE >>= 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES >>= 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId >>TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const >>ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId >>TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; >>const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId >>TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = >>20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const >>ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId >>TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; >>const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId >>TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; >>const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = >>32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId >>TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const >>ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY >>= 37; const ComponentId TAG_INET_SEC_TRANS = 123; }; The following >>additional components that can be used by other protocols are specified >>in the DCE ESIOP chapter of this document and CORBAServices, Security >>Service, in the Security Service for DCE ESIOP section (at page 13-19, >>13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId >>TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; >>const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId >>TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; >>const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The >>following is the description of our proposed supplement to CORBA core >>specification. We add one component into module IOP: const ComponentId >>TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The >>TAG_AIOR_LOGICALNAME component has an associated value of type string >>encoded as a CDR encapsulation. We have not defined the interface of >>mapping logical names to regular IOR because now this function is local >>and its interoperability is not necessary. But if two or more SPs want to >>exchange their mapping items to provide more intelegent services, we may >>need to define the coresponding interfaces. > > >================================= >Jürgen Boldt >Director, Member Services > >Object Management Group >250 First Avenue, Suite 100 >Needham, MA 02494 > >Tel. +1 781 444 0404 ext. 132 >Fax: +1 781 444 0320 >email: juergen@omg.org >www www.omg.org > >================================ ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ X-Sender: andyp@ussfex01.bea.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 16 Jul 2004 11:12:45 -0700 To: Juergen Boldt From: Andy Piper Subject: RE: issue 7592 -- Core RTF issue? Cc: "Ke Jin" , , At 11:06 AM 7/16/2004, Juergen Boldt wrote: Isn't the Firewall spec a dead fish in the water? The FTF report has not been adopted, so the spec is currently not finalized.. No idea. It would be a shame since this scenario is getting more and more prevalent andy Subject: RE: issue 7592 -- Core RTF issue? Date: Fri, 16 Jul 2004 14:58:51 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 7592 -- Core RTF issue? Thread-Index: AcRrYKS5SMlnL7F3SXu52iRkwIUf9QABagsw From: "Bergersen, Rebecca" To: "Andy Piper" , "Juergen Boldt" Cc: "Ke Jin" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6GJ7ilj023696 The Firewall spec is dead. The FTF timed out at the Orlando meeting with too many unresolved issues for the standard to be accepted by the AB. Regards, Rebecca Bergersen Principal Architect, Middleware Standards rebecca.bergersen@iona.com ------------------------------------------------------- IONA Technologies 200 West Street Waltham, MA 02451 USA Tel: (781) 902-8265 Fax: (781) 902-8001 ------------------------------------------------------- Making Software Work Together TM > -----Original Message----- > From: Andy Piper [mailto:andyp@bea.com] > Sent: Friday, July 16, 2004 2:13 PM > To: Juergen Boldt > Cc: Ke Jin; issues@omg.org; corba-rtf@omg.org > Subject: RE: issue 7592 -- Core RTF issue? > > > At 11:06 AM 7/16/2004, Juergen Boldt wrote: > >Isn't the Firewall spec a dead fish in the water? > >The FTF report has not been adopted, so the spec is > currently not finalized.. > > No idea. It would be a shame since this scenario is getting > more and more > prevalent > > andy > Date: Tue, 20 Jul 2004 11:08:18 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Juergen Boldt Cc: issues@omg.org, corba-rtf@omg.org Subject: Re: issue 7592 -- Core RTF issue? Sounds like a good starting point for writing an RFP, rather than an issue that an RTF can do anything about. It is asking for a new feature. Anyway, file it as an issue and we will see what to do with it. Jishnu. Juergen Boldt wrote: From: webmaster@omg.org Date: 15 Jul 2004 05:09:25 -0400 To: Subject: Issue/Bug Report ------------------------------------------------------------------------ * *Name: *jack_nudt * *Company: *Computer Science Department, National University of Defence Technology * *mailFrom: *jack_nudt@yahoo.com.cn * *Notification: *Yes * *Specification: *CommonObject Request Broker Architecture: Core Specification * *Section: *Chp. 13 * *FormalNumber: *formal * *Version: *3.0 * *RevisionDate: *02-11-03 * *Page: *13-17, 13-19 * *Nature: *Enhancement * *Severity: *Significant * *HTTP User Agent: *Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2) *Description* Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. +-------------+ +-------------+ | Client | Abstract IORs | Service | | application +-----------------++ Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | +---------------------------+ | | | BS2's IORs | | + +--------------+ | +------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server 1 | | Background | +------+-----+ +------------+ | Server 2 | | Background | +------------+ | Server 2 | +------------+ The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: A .secafretni gnidnopseroc eht enifed ot deen yam ew ,secivres tnegeletni erom edivorp ot smeti gnippam rieht egnahcxe ot tnaw sPS erom ro owt fi tuB .yrassecen ton si ytilibareporetni sti dna lacol si noitcnuf siht won esuaceb ROI raluger ot seman lacigol gnippam fo ecafretni eht denifed ton evah eW .noitaluspacne RDC a sa dedocne gnirts epyt fo eulav detaicossa na sah tnenopmoc EMANLACIGOL_ROIA_GAT ehT .dItnenopmoC denimretednu na si XXX // ;XXX = EMANLACIGOL_ROIA_GAT dItnenopmoC tsnoc :POI eludom otni tnenopmoc eno dda eW .noitacificeps eroc ABROC ot tnemelppus desoporp ruo fo noitpircsed eht si gniwollof ehT ecivreS ytiruceS // ;301 = HCEM_CES_ECD_GAT dItnenopmoC tsnoc ;201 = SEPIP_ON_ECD_GAT dItnenopmoC tsnoc ;101 = EMAN_GNIDNIB_ECD_GAT dItnenopmoC tsnoc ;001 = GNIDNIB_GNIRTS_ECD_GAT dItnenopmoC tsnoc ;21 = YCILOP_NOITACOL_GAT dItnenopmoC tsnoc ;6 = NOITISOP_DI_TNIOPDNE_GAT dItnenopmoC tsnoc ;5 = YEK_TCEJBO_ETELPMOC_GAT dItnenopmoC tsnoc :)02-31 ,91-31 egap ta( noitces POISE ECD rof ecivreS ytiruceS eht ni ,ecivreS ytiruceS ,secivreSABROC dna tnemucod siht fo retpahc POISE ECD eht ni deificeps era slocotorp rehto yb desu eb nac taht stnenopmoc lanoitidda gniwollof ehT ;} ;321 = SNART_CES_TENI_GAT dItnenopmoC tsnoc ;73 = YCILOP_YTIVITCA_GAT dItnenopmoC tsnoc ;63 = SNART_CES_SLT_GAT dItnenopmoC tsnoc ;53 = SNART_CES_POICES_GAT dItnenopmoC tsnoc ;43 = GAT_LLUN_GAT dItnenopmoC tsnoc ;33 = TSIL_HCEM_CES_ISC_GAT dItnenopmoC tsnoc ;23 = YCILOP_VNI_GAT dItnenopmoC tsnoc ;13 = YCILOP_STO_GAT dItnenopmoC tsnoc ;03 = SRETUOR_EGASSEM_GAT dItnenopmoC tsnoc ;62 = YCILOP_NOITCASNART_GAT dItnenopmoC tsnoc ;52 = ESABEDOC_AVAJ_GAT dItnenopmoC tsnoc ;42 = OFNI_TCATNOC_PCCS_GAT dItnenopmoC tsnoc ;32 = SNART_LLAWERIF_GAT dItnenopmoC tsnoc ;22 = HCEM_CES_CIRENEG _GAT dItnenopmoC tsnoc ;12 = HCEM_CES_cilbuP_AMCE_ISC_GAT dItnenopmoC tsnoc ;02 = SNART_CES_LSS_GAT dItnenopmoC tsnoc ;91 = HCEM_CES_dirbyH_AMCE_ISC_GAT dItnenopmoC tsnoc ;81 = HCEM_CES_terceS_AMCE_ISC_GAT dItnenopmoC tsnoc ;71 = HCEM_CES_5VsorebreK_GAT dItnenopmoC tsnoc ;61 = HCEM_CES_2_MKPS_GAT dItnenopmoC tsnoc ;51 = HCEM_CES_1_MKPS_GAT dItnenopmoC tsnoc ;41 = EMAN_CES_GAT dItnenopmoC tsnoc ;31 = SNOITPO_NOITAICOSSA_GAT dItnenopmoC tsnoc ;3 = SSERDDA_POII_ETANRETLA_GAT dItnenopmoC tsnoc ;2 = SEICILOP_GAT dItnenopmoC tsnoc ;1 = STES_EDOC_GAT dItnenopmoC tsnoc ;0 = EPYT_BRO_GAT dItnenopmoC tsnoc { POI eludom .)91-31 egap ta( ROI gnitsixe na morf stnenopmoc eseht pord ton tsum BRO nA .slocotorp rehto ro ,sPOISE ,sPOIG rehto ,POII ot ylppa yam dna ,seliforp STNENOPMOC_ELPITLUM_GAT dna POI_TENRETNI_GAT ni dedulcni eb nac taht stnenopmoc ROI dradnats era gniwollof ehT ;} ;eliforPtnenopmoCelpitluM >tnenopmoCdeggaT< ecneuqes fedepyt ;2 = POI_PCCS_GAT dIeliforP tsnoc ;1 = STNENOPMOC_ELPITLUM_GAT dIeliforP tsnoc ;0 = POI_TENRETNI_GAT dIeliforP tsnoc { POI eludom :)71-31 egap ta( seliforp ROI dradnats 3 senifed noitacificeps ABROC ;} ;qeStnenopmoCdeggaT >tnenopmoCdeggaTtetco< ecneuqes ;gat dItnenopmoC { tnenopmoCdeggaT tcurts ;dItnenopmoC gnol dengisnu fedepyt .eliforPdeggaT a ni detaluspacne eb dluow sihT // .seliforp tnenopmocitlum gnitneserper fo yaw dradnatS // ;} ;seliforp >eliforPdeggaT< ecneuqes ;di_epyt gnirts { ROI tcurts .DI epyt a sulp ,seliforp locotorp cificeps-tcejbo // fo ecneuqes a si ecnerefeR tcejbO elbareporetnI na // ; qeSeliforPdeggaT >eliforPdeggaT< ecneuqes fedepyt ;} ;atad_eliforp >tetco< ecneuqes ;gat dIeliforP { eliforPdeggaT tcurts ;dIeliforP gnol dengisnu fedepyt seulav gat eliforP locotorP dradnatS // LDI // { POI eludom .denifed eb lliw sdohtem dna secafretni tahw dna serutcurts atad ROI gnitsixe no desab ROIA troppus ot woh ssucsid lliw ew nehT .51-31 egap ta denifed ROI raluger fo erutcurts eht ta kool a evah s'tel yltsriF .ROI raluger ot elbitapmoc si ROIA fo erutcurts ehT .tseuqer gnimoc a rof revres dnuorgkcab ta tcejbo tegrat eht fo ROI raluger eht ot ROIA eht ni eman lacigol eht pam dna ,semoc tseuqer gnidnopserroc erofeb gnippam eht pu tes dluohs PS eht oS .revres dnuorgkcab no gninnur tcejbo na fo ROI na ot gnidnopserroc yleuqinu si eman lacigoL eman lacigol + ROI raluger s'PS = ROI ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ --