Issue 4141: ISL changes to break dependency on Security and SECIOP modules (csiv2-ftf) Source: Oracle (Mr. Ron Monzillo, ronald.monzillo(at)east.sun.com) Nature: Uncategorized Issue Severity: Summary: Document: orbos/2000-08-04 CSIv2 Final Submission Issue: Section "IDL" Contains dependencies on the IDL of the security specification (the SECURITY, SECIOP, and SSLIOP modules) Description: The IDL for CSIv2 is dependent on the AssociationOptions type of the SECURITY module, and proposes some new types to be added to that module. The IDL for CSIv2 also proposes some new types to be added to the the SECIOP module. The IDL for CSIv2 is dependent on the SSL module. Proposed Solution: 1. Move the AssociationOptions type out of the Security Mododule into a new base security module. (Issue for the security spec) - Make the Security Module dependent on this base security module. 2. Add new constants to AssociationOptions. 3. Add to this new base module the new types created for CSIv2 and previosly intended to be added to the security module (with the exception of the types related to type ScopedName, which will be the subject of another issue). 4. Move the new SECIOP ComponentId and tag structure for TAG_SECIOP SEC_TRANS into the CSIIOP module, thus eleiminating the CSIv2 dependence on the SECIOP module. 5. move the SSLIOP module into the CSIv2 spec. Change the SSLIOP modules dependency on the security module to a dependency on the new base security module. 6. Change All references to the SECUIRTY module in modules GSSUP, SSLIOP. CSI, and CSIIOP to references to the base security module. 7. Modify the GSSUP, CSI, and CSIIOP modules for idempotent inclusion. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. [1] Move definition of UTFString to CSI, and move NameValue and ScopedName to GSSUP (for now) Replace all the IDL definitions at the top of page 16-13, which are between para 48 & 49 with the following: typedef CSI::UTF8String NameValue; struct ScopedName { NameValue name_scope; NameValue name_value; }; // GSSUP::InitialContextToken struct InitialContextToken { ScopedName username; CSI::UTF8String password; }; [2] Change Reference to TAG_SSL_SEC_TRANS on page 16-29 in para 114 to TAG_TLS_SEC_TRANS. [3] Change Section Header "TAG_SSL_SEC_TRANS" on page 16-33 above para 126 to "TAG_TLS_SEC_TRANS" [4] Change all occurrences of TAG_SSL_SEC_TRANS" from para 126 thru para 128, to "TAG_TLS_SEC_TRANS". [5] Change idl between para 127 & 128 to the following: const IOP::ComponentId TAG_TLS_SEC_TRANS = 999; // TBA struct TLS_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; unsigned short port; }; [6] Change the IDL between para 130 & 131 to the following: const IOP::ComponentId TAG_SECIOP_SEC_TRANS = 35; struct SECIOP_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; CSI::OID mech_oid; CSI::GSS_NT_ExportedName target_name; unsigned short port; }; [7] Change the IDL between para 132 & 133, removing the "Security::" module name making the CompoundSecMech struct have the following definition: struct CompoundSecMech { AssociationOptions target_requires; IOP::TaggedComponent transport_mech; AS_ContextSec as_context_mech; SAS_ContextSec sas_context_mech; }; [8] Change the TAG_SSL_SEC_TRANS to TAG_TLS_SEC_TRANS in para 133. [9] Change the IDL between para 138 & 139 to the following: struct AS_ContextSec{ AssociationOptions target_supports; AssociationOptions target_requires; CSI::OID client_authentication_mech; sequence <CSI::GSS_NT_ExportedName> target_name; }; [10] In the IDL between para 144 and 145, change the definition of the SAS_ContextSec struct to the following: struct SAS_ContextSec{ AssociationOptions target_supports; AssociationOptions target_requires; sequence <ServiceConfiguration> privilege_authorities; CSI::OIDList supported_naming_mechanisms; }; [11] Change occurrence of TAG_SSL_SEC_TRANS to TAG_TLS_SEC_TRANS in the code after para 187 and in para 188. [12] Change occurrence of TAG_SSL_SEC_TRANS to TAG_TLS_SEC_TRANS in the code after para 189. [13] Change occurrence of TAG_SSL_SEC_TRANS to TAG_TLS_SEC_TRANS in the code after para 190. [14] Change occurrence of TAG_SSL_SEC_TRANS to TAG_TLS_SEC_TRANS in the code after para 192. [15] Change occurrence of TAG_SSL_SEC_TRANS to TAG_TLS_SEC_TRANS in the code after para 193. [16] Remove Section 16.9.2 Module Security in its entirety. [17] Remove Section 16.9.3 Module SSLIOP in its entirety. [18] Remove Section 16.9.4 Module SECIOP in its entirety. [19] Change IDL of the GSSUP mechanism to the following: #ifndef _GSSUP_IDL_ #define _GSSUP_IDL_ #include <CSI.idl> #pragma prefix "omg.org" module GSSUP { typedef CSI::UTF8String NameValue; struct ScopedName { NameValue name_scope; NameValue name_value; }; // The GSS Object Identifier allocated for the username/password mechanism is defined below. // // { iso-itu-t (2) international-organization (23) omg (130) security (1) // authentication (1) gssup-mechanism (1) } // The following structure defines the inner contents of the username password initial // context token. This structure is CDR encoded in a sequence of octets and appended // at the end of the username/password GSS (initial context) Token (see above). struct InitialContextToken { ScopedName username; CSI::UTF8String password; }; }; // GSSUP #endif [20] In Section 16.9.6 Modules CSI, Add the following to the beginning: #ifndef _CSI_IDL_ #define _CSI_IDL_ #pragma prefix "omg.org" [21] After "module CSI {" add the following lines of IDL: // An X509CertificateChain contains an ASN.1 encoded SEQUENCE // [1..MAX] OF X.509 certificates encapsulated in a sequence // of octets. The subject's certificate must come first in the // list. Each following certificate must directly certify the one // preceding it. The ASN.1 representation of Certificate is // as defined in [IETF RFC 2459]. typedef sequence <octet> X509CertificateChain; // an X.501 type name or Distinguished Name encapsulated in a sequence of octets // containing the ASN.1 encoding. typedef sequence <octet> X501DistinguishedName; // UTF-8 Encoding of String typedef sequence <octet> UTF8String; // ASN.1 Encoding of an OBJECT IDENTIFIER typedef sequence <octet> OID; typedef sequence <OID> OIDList; // A sequence of octets containing a GSStoken. Initial context tokens are ASN.1 // encoded as defined in [IETF RFC 2743] Section 3.1, "Mechanism-Independent Token // Format", pp. 81-82. Initial context tokens contain an ASN.1 tag followed by a // token length, a mechanism identifier, and a mechanism-specific // token (i.e. a GSSUP::InitialContextToken). The encoding of all other GSS tokens // (e.g. error tokens and final context tokens) is mechanism dependent. typedef sequence <octet> GSSToken; // An encoding of a GSS Mechanism-Independent Exported Name Object as defined in // [IETF RFC 2743] Section 3.2, "GSS Mechanism-Independent Exported Name Object // Format," p. 84. typedef sequence <octet> GSS_NT_ExportedName; typedef sequence <GSS_NT_ExportedName> GSS_NT_ExportedNameList; [22] Remove all 6 occurrences of "Security::" in the IDL for the CSI module. [23] Add the following line to the end of the CSI module: #endif [24] In section 16.9.7 add the following to the beginning: #ifndef _CSIIOP_IDL_ #define _CSIIOP_IDL_ #include <IOP.idl> #include <CSI.idl> #pragma prefix "omg.org" [25] In section 16.9.7, after the definition of TAG_CSI_SEC_MECH_LIST add the following IDL: // // Association Options // typedef unsigned short AssociationOptions; const AssociationOptions NoProtection = 1; const AssociationOptions Integrity = 2; const AssociationOptions Confidentiality = 4; const AssociationOptions DetectReplay = 8; const AssociationOptions DetectMisordering = 16; const AssociationOptions EstablishTrustInTarget = 32; const AssociationOptions EstablishTrustInClient = 64; const AssociationOptions NoDelegation = 128; const AssociationOptions SimpleDelegation = 256; const AssociationOptions CompositeDelegation = 512; const AssociationOptions IdentityAssertion = 1024; const AssociationOptions DelegationByClient = 2048; [26] In section 16.9.7, Replace all 5 occurrences of "Security::AssociationOptions" with "AssociationOptions". These occurrences are in the following definitions: AS_ContextSec SAS_ContextSec CompoundSecMech Replace all remaining 3 occurrences of "Security::" with "CSI::". These occurrences are in the following definitions: AS_ContextSec SAS_ContextSec [27] In section 16.9.7, replace the final "};//CSIIOP" with the following IDL: const IOP::ComponentId TAG_SECIOP_SEC_TRANS = 35; struct SECIOP_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; CSI::OID mech_oid; CSI::GSS_NT_ExportedName target_name; unsigned short port; }; const IOP::ComponentId TAG_TLS_SEC_TRANS = 9999; //TBA struct TLS_SEC_TRANS { AssociationOptions target_supports; AssociationOptions target_requires; unsigned short port; }; }; //CSIIOP #endif Actions taken: January 10, 2001: received issue October 3, 2001: closed issue Discussion: Elimination of dependencies on the Security, SECIOP, and SSLIOP modules is generally felt to be a good idea. Move pertinent data definitions from Security, SECIOP, and SSLIOP into CSI module and CSIIOP module. End of Annotations:===== Date: Wed, 10 Jan 2001 10:00:33 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org, issues@omg.org Subject: ISSUE: ISL changes to break dependency on Security and SECIOP modules Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ie\d9&-k!!ohad9@T$!! Document: orbos/2000-08-04 CSIv2 Final Submission Issue: Section "IDL" Contains dependencies on the IDL of the security specification (the SECURITY, SECIOP, and SSLIOP modules) Description: The IDL for CSIv2 is dependent on the AssociationOptions type of the SECURITY module, and proposes some new types to be added to that module. The IDL for CSIv2 also proposes some new types to be added to the the SECIOP module. The IDL for CSIv2 is dependent on the SSL module. Proposed Solution: 1. Move the AssociationOptions type out of the Security Mododule into a new base security module. (Issue for the security spec) - Make the Security Module dependent on this base security module. 2. Add new constants to AssociationOptions. 3. Add to this new base module the new types created for CSIv2 and previosly intended to be added to the security module (with the exception of the types related to type ScopedName, which will be the subject of another issue). 4. Move the new SECIOP ComponentId and tag structure for TAG_SECIOP SEC_TRANS into the CSIIOP module, thus eleiminating the CSIv2 dependence on the SECIOP module. 5. move the SSLIOP module into the CSIv2 spec. Change the SSLIOP modules dependency on the security module to a dependency on the new base security module. 6. Change All references to the SECUIRTY module in modules GSSUP, SSLIOP. CSI, and CSIIOP to references to the base security module. 7. Modify the GSSUP, CSI, and CSIIOP modules for idempotent inclusion. ---- Source code diffs of these changes will be provided for your consideration. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Jan 2001 10:36:42 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org, issues@omg.org Subject: Re: ISSUE: ISL changes to break dependency on Security and SECIOP modules In-Reply-To: <3A5C7911.C42F5D96@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: A`*e9M;Le9f%U!!V_md9 Discusson on New Issue # 1: I agree with the assement of clearing the dependency of the CSI modules on the current Security modules. However, I think there is a slightly better approach to Ron's Proposal. On Wed, 10 Jan 2001, Ron Monzillo wrote: > Document: orbos/2000-08-04 CSIv2 Final Submission > Issue: > > Section "IDL" Contains dependencies on the IDL of the security > specification (the SECURITY, SECIOP, and SSLIOP modules) > > Description: > > The IDL for CSIv2 is dependent on the AssociationOptions type of the > SECURITY module, and proposes some new types to be added to that > module. > > The IDL for CSIv2 also proposes some new types to be added to the > the > SECIOP module. > > The IDL for CSIv2 is dependent on the SSL module. > > Proposed Solution: > > 1. Move the AssociationOptions type out of the Security Mododule > into a > new base security module. (Issue for the security spec) - Make the > Security Module dependent on this base security module. You won't be able to do that. I suggest making a parallel type in a module of CSI. It will just be a matter of forced coincidence that the association options that are CSI related are related to the ones in Security. In fact, I think they can go in CSIIOP without much thought. They are not needed beyond that scope. The other types we put in Security may have a problem requiring a new "base" CSI security module. > 2. Add new constants to AssociationOptions. > > 3. Add to this new base module the new types created for CSIv2 and > previosly intended to be added to the security module (with the > exception of the types related to type ScopedName, which will be the > subject of another issue). > > 4. Move the new SECIOP ComponentId and tag structure for TAG_SECIOP > SEC_TRANS into the CSIIOP module, thus eleiminating the CSIv2 dependence > on the SECIOP module. I agree with this. > 5. move the SSLIOP module into the CSIv2 spec. Change the SSLIOP modules > dependency on the security module to a dependency on the new base > security module. I do not agree with this approach. The SSL module should be left where it is, so that it can still work with older CSIv1 SSL. The fact that CSI uses its own association options and SSL component uses the ones from Security, doesn't much matter. > 6. Change All references to the SECUIRTY module in modules GSSUP, > SSLIOP. CSI, and CSIIOP to references to the base security module. We'll have to discuss this further. Perhaps this will be an issue for the teleconference. > 7. Modify the GSSUP, CSI, and CSIIOP modules for idempotent inclusion. that was done already wasn't it? > > ---- > > Source code diffs of these changes will be provided for your > consideration. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 10 Jan 2001 13:52:21 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: csiv2-ftf@omg.org, issues@omg.org Subject: Re: ISSUE: ISL changes to break dependency on Security and SECIOP modules References: <3A5C7911.C42F5D96@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: XKe!!XSSd9/2k!!1G\!! In today's teleconference 3 approaches to resolving this issue were proposed. Proposal 1 The SECURITY module would be separated into two files; one that includes the other. The included file would contain the base security module definitions (i.e AssociationOptions). The other types invented for CSIv2 and intended for the SECURITY module would instead be added to the CSI module. The included file would also be included in the CSI and SSLIOP modules in place of security.idl. The GSSUP specific types that were proposed for the security module would be placed in the GSSUP module. The SECIOP related tag and type would be placed in the CSIIOP module. Depending on the resolution of issue 3948 and or the potential placement of the UTF8String type in the CSI module as apposed to the GSSUP module, the CSI module, may need to be included in the GSSUP module. Proposal 2 A clone of the Security::AssociationOptions type would be added to the CSI module (and kept in sync with its counterpart in the security module). The other types invented for CSIv2 and intended by the submission to be added to the SECURITY module, would instead be added to the CSI module. The CSI module would be included in the CSIIOP module (in place of security.idl). This proposal anticipates that there will be a trivial mapping of Security::AssociationOptions and CSI::AssociationsOptions based on both types being simple numerical types and that the enumerations are "coincident". (the rest is the same as for Proposal 1) The GSSUP specific types that were proposed for the security module would be placed in the GSSUP module. The SECIOP related tag and type would be placed in the CSIIOP module. Depending on the resolution of issue 3948 and or the potential placement of the UTF8String type in the CSI module as apposed to the GSSUP module, the CSI module, may need to be included in the GSSUP module. Proposal 3 A clone is made of the contents of the SSLIOP module and added to the CSIIOP module. Some discussion occurred concerning the reuse of the existing tag value, although it may turn out to be necessary to define a new tag value for the clone. The other types invented for CSIv2 and intended by the submission to be added to the SECURITY module, would instead be added to the CSI module. The CSI module would be included in the CSIIOP module (in place of security.idl). (the rest is the same as for Proposal 1) The GSSUP specific types that were proposed for the security module would be placed in the GSSUP module. The SECIOP related tag and type would be placed in the CSIIOP module. Depending on the resolution of issue 3948 and or the potential placement of the UTF8String type in the CSI module as apposed to the GSSUP module, the CSI module, may need to be included in the GSSUP module. Ron Monzillo wrote: > > Document: orbos/2000-08-04 CSIv2 Final Submission > Issue: > > Section "IDL" Contains dependencies on the IDL of the security > specification (the SECURITY, SECIOP, and SSLIOP modules) > > Description: > > The IDL for CSIv2 is dependent on the AssociationOptions type of the > SECURITY module, and proposes some new types to be added to that module. > > The IDL for CSIv2 also proposes some new types to be added to the the > SECIOP module. > > The IDL for CSIv2 is dependent on the SSL module. > > Proposed Solution: > > 1. Move the AssociationOptions type out of the Security Mododule into a > new base security module. (Issue for the security spec) - Make the > Security Module dependent on this base security module. > > 2. Add new constants to AssociationOptions. > > 3. Add to this new base module the new types created for CSIv2 and > previosly intended to be added to the security module (with the > exception of the types related to type ScopedName, which will be the > subject of another issue). > > 4. Move the new SECIOP ComponentId and tag structure for TAG_SECIOP > SEC_TRANS into the CSIIOP module, thus eleiminating the CSIv2 dependence > on the SECIOP module. > > 5. move the SSLIOP module into the CSIv2 spec. Change the SSLIOP modules > dependency on the security module to a dependency on the new base > security module. > > 6. Change All references to the SECUIRTY module in modules GSSUP, > SSLIOP. CSI, and CSIIOP to references to the base security module. > > 7. Modify the GSSUP, CSI, and CSIIOP modules for idempotent inclusion. > > ---- > > Source code diffs of these changes will be provided for your > consideration. Date: Thu, 11 Jan 2001 10:33:17 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: csiv2-ftf@omg.org, issues@omg.org Subject: Re: ISSUE: ISL changes to break dependency on Security and SECIOP modules References: <3A5C7911.C42F5D96@east.sun.com> <3A5CAF65.DAEF6046@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =$3!!T9h!!jf ... > > Proposal 3 > > A clone is made of the contents of the SSLIOP module and added to the > CSIIOP module. Some discussion occurred concerning the reuse of the > existing tag value, although it may turn out to be necessary to define a > new tag value for the clone. The other types invented for CSIv2 and > intended by the submission to be added to the SECURITY module, would > instead be added to the CSI module. The CSI module would be included in > the CSIIOP module (in place of security.idl). > > (the rest is the same as for Proposal 1) > > The GSSUP specific types that were proposed for the security module > would be placed in the GSSUP module. > > The SECIOP related tag and type would be placed in the CSIIOP module. > > Depending on the resolution of issue 3948 and or the potential placement > of the UTF8String type in the CSI module as apposed to the GSSUP module, > the CSI module, may need to be included in the GSSUP module. > ... X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 17 Jan 2001 23:27:36 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Vote Resolution for Issue ISLCBDSS Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427817617-855729612-979792056=:21162" X-UIDL: eWEe9/l=!!R$k!!M_Td9 Issue ISLCBDSS: ISL changes to break dependency on Security and SECIOP modules As promised, the attached resolution is for the initial moving around of definitions to CSI and CSIIOP modules. I also tacked on the #ifdefs and #pragma prefix "omg.org" stuff. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com [] FTF-Issue-ISLCBDSS.html Date: Wed, 24 Jan 2001 13:38:06 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: andrew@omg.org, tag-request@omg.org, csiv2-ftf@omg.org Subject: Issue 4141: ISL changes to break dependency on Security and SECIOP Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,5Qe9kl;!!8URd9HaE!! Andrew, The CSIv2 FTF would like your help in reserving a new tagged component identifier value. We would like this identifier to be called "TAG_TLS_SEC_TRANS" and for it to be assigned the value 36. That is: TAG_TLS_SEC_TRANS = 36; Thanks, Ron X-Sender: andrew@emerald.omg.org Message-Id: In-Reply-To: <3A6F210E.688F663B@east.sun.com> Mime-Version: 1.0 Date: Thu, 25 Jan 2001 17:34:22 +0000 To: Ron Monzillo From: Andrew Watson Subject: Re: Issue 4141: ISL changes to break dependency on Security and SECIOP Cc: csiv2-ftf@omg.org, jishnu_mukerji@omg.org Content-Type: text/plain; charset="us-ascii" X-UIDL: c"K!!Z3Ne9?HQ!!jfjd9 Ron, You wrote: > We would like this identifier to be called "TAG_TLS_SEC_TRANS" > and for it to be assigned the value 36. That is: > > TAG_TLS_SEC_TRANS = 36; You have it. It'll be in the next publication of the OMG tags list. Cheers, Andrew