Issue 2094: get_security_names (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: e have a SecurityMechandNameList get_security_names(in Object objref); on SecurityLevel2::Current. Since we have this capability, we should have a similar way of getting the mechanisms and options. Unfortunately, Security::MechandOptions struct only contains options supported and does not have options required. The only place it is used is for Vault::get_supported_mechs(); We should probably have another structure to handle the mechs on the object reference. We will call this the mechanism data as not to confuse it with MechandOptions struct. Resolution: :Current. Revised Text: Actions taken: October 16, 1998: received issue November 13, 1998: closed issue Discussion: :MechandOptions struct only contains options End of Annotations:===== Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 16 Oct 1998 17:23:02 -0400 (EDT) From: Polar Humenn To: secsig@omg.org, sec-rev@omg.org Subject: get_security_names We have a SecurityMechandNameList get_security_names(in Object objref); on SecurityLevel2::Current. Since we have this capability, we should have a similar way of getting the mechanisms and options. Unfortunately, Security::MechandOptions struct only contains options supported and does not have options required. The only place it is used is for Vault::get_supported_mechs(); We should probably have another structure to handle the mechs on the object reference. We will call this the mechanism data as not to confuse it with MechandOptions struct. module Security { struct SecurityMechanismData { MechanismType mechanism; AssociationOptions options_supported; AssociationOptions options_required; }; typedef sequence SecurityMechanismDataList; }; module SecurityLevel2 { interface Current { SecurityMechanismDataList get_security_mechanisms( in Object objref ); }; }; I will put this in revision document. ONE OTHER POINT: Should we just deprecate get_security_names() and put the security name in the SecurityMechanismData struct? Please comment! -Polar ------------------------------------------------------------------- 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 Return-Path: To: Polar Humenn Cc: secsig@omg.org, sec-rev@omg.org Subject: Re: get_security_names Reply-To: andre@inprise.com X-Disclaimer: These are my statements and opinions. Mine Mine Mine Mine. X-Disclaimer: To assume or infer that these statements represent X-Disclaimer: Inprise Corporation would be, without a doubt, your error. Date: Fri, 16 Oct 1998 14:30:44 -0700 From: "Andre Srinivasan" PH> ONE OTHER POINT: Should we just deprecate get_security_names() and PH> put the security name in the SecurityMechanismData struct? Yes; it makes sense and simplifies. -andre. Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 19 Oct 1998 11:02:15 -0400 (EDT) From: Polar Humenn To: secsig@omg.org, sec-rev@omg.org Subject: get_security_names (fwd) Due to some positive response to this issue labeled "ONE OTHER POINT", I think we will go with the following, and include the security name in the struct. Note, it will still be an issue of whether to formally deprecate the "get_security_names" operation. module Security { struct SecurityMechanismData { MechanismType mechanism; SecurityName security_name; AssociationOptions options_supported; AssociationOptions options_required; }; typedef sequence SecurityMechanismDataList; }; module SecurityLevel2 { interface Current { SecurityMechanismDataList get_security_mechanisms( in Object objref ); }; }; ------------------------------------------------------------------- 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 ---------- Forwarded message ---------- Date: Fri, 16 Oct 1998 17:23:02 -0400 (EDT) From: Polar Humenn To: secsig@omg.org, sec-rev@omg.org Subject: get_security_names We have a SecurityMechandNameList get_security_names(in Object objref); on SecurityLevel2::Current. Since we have this capability, we should have a similar way of getting the mechanisms and options. Unfortunately, Security::MechandOptions struct only contains options supported and does not have options required. The only place it is used is for Vault::get_supported_mechs(); We should probably have another structure to handle the mechs on the object reference. We will call this the mechanism data as not to confuse it with MechandOptions struct. module Security { struct SecurityMechanismData { MechanismType mechanism; AssociationOptions options_supported; AssociationOptions options_required; }; typedef sequence SecurityMechanismDataList; }; module SecurityLevel2 { interface Current { SecurityMechanismDataList get_security_mechanisms( in Object objref ); }; }; I will put this in revision document. ONE OTHER POINT: Should we just deprecate get_security_names() and put the security name in the SecurityMechanismData struct? Please comment! -Polar ------------------------------------------------------------------- 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 Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Mon, 19 Oct 98 09:28:34 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Mon, 19 Oct 98 09:16:51 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Mon, 19 Oct 98 09:25:57 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Mon, 19 Oct 98 09:25:57 +0100 Date: Mon, 19 Oct 98 09:25:57 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015219] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15219 Priority: normal From: "NC Battle" To: polar@adiron.com Cc: secsig@omg.org, sec-rev@omg.org References: Importance: normal Subject: RE: get_security_names Polar, > We have a SecurityMechandNameList get_security_names(in Object objref); on SecurityLevel2::Current. Isn't that SecurityLevel2::Object, or did it move? > ONE OTHER POINT: Should we just deprecate get_security_names() and put the security name in the SecurityMechanismData struct? That sounds reasonable. I had one knee-jerk reaction to the idea though: I'm worried about the business in (what used to be) appendix E.6.2 (now D.6.2?) - applications have to check an IOR's security name unless they can obtain objrefs securely somehow. I know simply moving the information doesn't change the need to check it, but the more we obscure the interface to make the check, the more we are discouraging application writers from making the check at all(?). How many secure application writers do you think are fully aware of the security implications of not using get_security_names() as per D.6.2? -nick Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 19 Oct 1998 15:46:55 -0400 (EDT) From: Polar Humenn To: NC Battle cc: secsig@omg.org, sec-rev@omg.org Subject: RE: get_security_names On Mon, 19 Oct 1998, NC Battle wrote: > Polar, > > > We have a SecurityMechandNameList get_security_names(in Object > objref); > on SecurityLevel2::Current. > > Isn't that SecurityLevel2::Object, or did it move? SecurityLeve2::Object has been deprecated. > > ONE OTHER POINT: Should we just deprecate get_security_names() and put the > security name in the SecurityMechanismData struct? > > That sounds reasonable. Good. Thanks. > I had one knee-jerk reaction to the idea though: I'm > worried about the business in (what used to be) appendix E.6.2 (now > D.6.2?) - > applications have to check an IOR's security name unless they can > obtain > objrefs securely somehow. I know simply moving the information > doesn't change > the need to check it, but the more we obscure the interface to make > the check, > the more we are discouraging application writers from making the > check at > all(?). I suppose you mean, that it's obscure that we must give the object reference to the security service to findout what its security names are, as opposed to having an operation on the object reference itself. I would agree, however, it makes it difficult, if one where to install a security service into an ORB that doesn't know about security services, just interceptors. That would require some sort of interceptor that would be given the IOR structure and to be able to supply a value for such a function. This approach might not be a bad idea. Because, as it stands now, a third party security service, in order to support that operation, needs to perform an object_to_string() on the object reference and pull apart the IOR that way, extremely inefficient. > How many secure application writers do you think are fully aware of the > security implications of not using get_security_names() as per D.6.2? I couldn't say. Some people just might consider its okay if there was mutual authentication and encryption, never mind who they are talking to. You know, sort of like how SSL does it. Later, -Polar ------------------------------------------------------------------- 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 Return-Path: To: Polar Humenn Cc: secsig@omg.org, sec-rev@omg.org Subject: Re: get_security_names Reply-To: andre@inprise.com X-Disclaimer: These are my statements and opinions. Mine Mine Mine Mine. X-Disclaimer: To assume or infer that these statements represent X-Disclaimer: Inprise Corporation would be, without a doubt, your error. Date: Mon, 19 Oct 1998 13:10:41 -0700 From: "Andre Srinivasan" ... >> How many secure application writers do you think are fully aware of >> the security implications of not using get_security_names() as per >> D.6.2? PH> I couldn't say. Some people just might consider its okay if there PH> was mutual authentication and encryption, never mind who they are PH> talking to. You know, sort of like how SSL does it. Ummm... SSL the protocol specification should not be confused with an SSL based the product. In most implementations, I've seen a way is exposed for the app to make sure that not only did the certificate chain check out computationally, but semantically as well (the catch phrases are trusted identity, trusted certificate or trustpoint). -andre.