Issue 2451: Channel Bindings are underspecified (sec-rev) Source: (, ) Nature: Enhancement Severity: Significant Summary: Summary: The channel bindings are described for operations, init_security_context, and accept_security_context in SecurityReplaceable::Vault, as Security::Opaque with no specification of what this looks like. This is a severe problem with the "Replaceability" of vaults, as SecIOP would like to place the channel bindings to any security context. Since the Vault, and SecurityContext were modeled after the GSS, I suggest that we adopt the GSS channel binding structure. Resolution: Close issue 2451 "Channel Bindings are underspecified" Revised Text: "chan_bindings" parameter to "Security::ChannelBindings": AssociationStatus init_security_context( in Credentials creds, in SecurityName target_security_name, in Object target, in DelegationMode delegation_mode, in OptionsDirectionPairList association_options, in MechanismType mechanism, in Opaque mech_data, //from IOR in ChannelBindings chan_bindings, out OpaqueBuffer security_token, out ClientSecurityContext security_context ); Change the definition of chan_binding parameter to: chan_bindings The channel bindings for the security context. They are the channel bindings defined for the GSS-API. Modify the IDL on page 15-172 changing the type of the "chan_bindings" parameter to "Security::ChannelBindings": AssociationStatus accept_security_context( in CredentialsList creds_list, in ChannelBindings chan_bindings, in Opaque in_token, out OpaqueBuffer out_token, out ServerSecurityContext security_context ); Change the definition of chan_binding parameter to: chan_bindings The channel bindings for the security context. They are the channel bindings defined for the GSS-API. Appendix A.2: Add definition of ChannelBindings: // GSS-API Channel Bindings struct ChannelBindings { unsigned long initiator_addrtype; sequence<octet> initiator_address; unsigned long acceptor_addrtype; sequence<octet> acceptor_address; sequence<octet> application_data; }; Actions taken: February 12, 1999: received issue June 18, 1999: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 12 Feb 1999 07:52:37 -0500 (EST) From: Polar Humenn To: issues@omg.org cc: secsig@omg.org, sec-rev@omg.org Subject: Issue: Channel Bindings Document: Security Chapter 15 Severity: Critical Subject: Channel Bindings are underspecified Description: The channel bindings are described for operations, init_security_context, and accept_security_context in SecurityReplaceable::Vault, as Security::Opaque with no specification of what this looks like. This is a severe problem with the "Replaceability" of vaults, as SecIOP would like to place the channel bindings to any security context. Since the Vault, and SecurityContext were modeled after the GSS, I suggest that we adopt the GSS channel binding structure. module Security { struct ChannelBindings { unsigned long initiator_addrtype; sequence initiator_address; unsigned long acceptor_addrtype; sequence acceptor_address; sequence application_data; }; }; Values for initiator_addrtype, and acceptor_addrtype, and the corresponding formats for initiator_address and acceptor_address are defined by the GSS-API. (i.e. internet addresses are specified by the constant GSS_C_AF_INET, and the corresponding address is a 4 byte (IPv4) or 8 byte (IPv6) network address) We can optionally include GSS_C_AF_* constants in the security module. Next, is what to do about Vault::init_security_context, and Vault::accept_security_context interfaces? Each of these functions take the Security::Opaque for the channel_bindings parameter. We can either change this to Security:ChannelBindings, or stipulate that the channel_bindings argument must be a CDR encapsulation of the the Security::ChannelBindings structure. It is a locality constrained interface, so no major version numbers really need to be changed. I would recomend changing the interface, because marshalling the channel bindings structure would add to performance problems. ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Mar 1999 10:41:26 -0500 (EST) From: Polar Humenn To: sec-rev@omg.org Subject: Re: Open Issues On 9 Mar 1999, Andre Srinivasan wrote: > Issue 2451: We need discussion. This issue is about creating and using channel bindings. I proposed to create a IDL structure for channel bindings that is isomorphic to the GSS-API structure for channel bindings. It is a well defined structure, which possibly has different mappings in different programming languages. Currently, the channel bindings supplied in init_security_context and accept_security_context are just Opaque, which would lead to mechanism specific coding rules. This was not the intent of the GSS-API. What I proposed is the "IDL" language mapping for the GSS Channel Bindings structure. ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com