Issues for Security 1.8 and 1.9 Revision Task Forces discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 357: The generate_token and verify_evidence methods have problems Jira Issue SEC19-1
Issue 371: Jira Issue SEC19-2
Issue 374: How does get_effective_rights get the delegation state? Jira Issue SEC19-3
Issue 998: AccessPolicy can"t distinguish intiator and delegates Jira Issue SEC14-1
Issue 1404: Typo in 98-01-02 Jira Issue SEC14-2
Issue 1756: Semantics of the Mechanism Policy is not defined wel Jira Issue SEC14-3
Issue 1757: Operations regarding Security Features Jira Issue SEC14-4
Issue 1758: Inconsistent Spelling between Security and SecurityLevel2 Jira Issue SEC14-5
Issue 1759: Misspelling Jira Issue SEC14-6
Issue 1760: Duplicate DelegationMode(s) in Security and SecurityLevel2 Jira Issue SEC14-7
Issue 1761: DelegationDirectivePolicy Needed Jira Issue SEC14-8
Issue 1763: Credentials issue Jira Issue SEC14-9
Issue 1764: Security Context does not reveal client/server orientation. Jira Issue SEC14-10
Issue 1766: Credentials not in SecurityReplaceable. Jira Issue SEC14-11
Issue 1767: Credentials and PrincipalAuthenticator should be in SecurityReplaceable Jira Issue SEC14-12
Issue 1768: SecurityFeatures still confusing! Jira Issue SEC14-13
Issue 1786: Using SecurityOpaque causes needless buffer copying Jira Issue SEC14-14
Issue 1787: Current:get_policy() is semanitically insconsitent with curr. object mode Jira Issue SEC14-15
Issue 2028: own-cedentials model Jira Issue SEC14-16
Issue 2030: Inconsistency between IDL and spec Jira Issue SEC14-17
Issue 2033: Construction Policy Jira Issue SEC14-18
Issue 2069: CORBA::PolicyManager Jira Issue SEC14-19
Issue 2086: SecurityAdmin Policies Jira Issue SEC14-20
Issue 2201: Interfaces are specified using wrong datatype in CORBASEC Jira Issue SEC14-21
Issue 2558: ReceivedCredentials. Jira Issue SEC14-22
Issue 2707: Jira Issue SEC14-23
Issue 2709: Jira Issue SEC14-24
Issue 2710: Jira Issue SEC14-25
Issue 2711: Jira Issue SEC14-26
Issue 2715: Jira Issue SEC14-27
Issue 2716: Jira Issue SEC14-28
Issue 2717: Jira Issue SEC14-29
Issue 2718: Jira Issue SEC14-30
Issue 2719: Jira Issue SEC14-31
Issue 2720: Jira Issue SEC14-32
Issue 2722: Jira Issue SEC14-33
Issue 2723: Jira Issue SEC14-34
Issue 2724: Jira Issue SEC14-35
Issue 2732: Jira Issue SEC14-36
Issue 2733: Jira Issue SEC14-37
Issue 2734: Jira Issue SEC14-38
Issue 2735: Jira Issue SEC14-39
Issue 2736: Jira Issue SEC14-40
Issue 2927: Parameters of locality constrained interfaces were using "sequence octet" Jira Issue SEC14-41
Issue 2928: The RequiredRights are confusing Jira Issue SEC14-42
Issue 2958: Security: Need to complete SecurityReplaceable Jira Issue SEC14-43
Issue 3044: Section: 15.7 Security Implementers Interfaces. Jira Issue SEC14-44
Issue 3045: Section: 15.8.14 CORBA Interface Jira Issue SEC14-45
Issue 3046: Section: Appendix I: Dangeling References Jira Issue SEC14-46
Issue 3047: Need TaggedComponentList typedef. Jira Issue SEC14-47
Issue 3406: Firewall issue regarding SOCKS Jira Issue SEC14-48
Issue 3407: Adding firewall info to the IOR Jira Issue SEC14-49
Issue 5526: SECIOP ContextId Jira Issue SEC14-50
Issue 5527: SECIOP State Machine Discard Jira Issue SEC14-51

Issue 357: The generate_token and verify_evidence methods have problems (sec-rev)

Summary: 1. There is a"request" It starts talking about partners What are partners? 2. input_buffer_complete and token_buffer_complete are flags. There is bno wat to link a series of calls together 

Summary: Internally in DAPs get_effective_rights [15-131] when turning Cred attributes int0 rights using policy, I need delegation state for each attribute.They don"t contain their delegation state. 

Summary: Locality constraint on credentials makes it technically impossible to pass them across this interface in cases where the recipient AccessPolicy object takes delegation explicitly into account. A possible partial fix wouldbe to change the interface (see corresponding issue file..) 

Summary: I believe there is a typo in 98-01-02 p.15-277. The line   	const AssociationOptions DetectReply = 8;   should read:          const AssociationOptions DetectReplay = 8;    

Summary: Semantics of the Mechanism Policy is not defined well.   There are different semantics if it is applied to a    client object reference than to a server object reference.      On the server side, the mechanism list stipulates which   mechanisms can be used to handle the requests. This may   stipulate which mechanisms are advertised in the IOR.      However, since there is an order, and order preference should   be specified. If a client wishes to invoke on said object and   two mechanisms support the requested features, the first one   that does so in the IOR should be said to be selected.       To support multiple mechanisms on the client side, one would    have to inquire which one was used and in which order to   use them. This can also be implied by the order of the list.      However, the semantics of such should be specified.    

Summary: Operations regarding Security Features are too vague, unclear,   can be inconsistent, and most likely, not fully implementable.    

 received issue

Summary: Inconsistent Spelling between Security  and SecurityLevel2    

 closed issue

Summary: const EventType AuditObectjCreation = 7;      should be      const EventType AuditObjectCreation = 7;    

 Security RTF 1.5 action 3 in ptc/98-11-02

Summary: Duplicate DelegationMode(s) in Security and SecurityLevel2    

 closed issue

Summary: We need a delegation directive policy in order to convey on an   object reference, and elsewhere, that whether the credentials   beign used are to be delegated or not.          

 Security RTF 1.5 action 6 in ptc/98-11-02

Summary: Credentials do not have a mechanism specification, a delegation mode,   specification, and an origin specification.      I believe the credentials object may be used to hold the means   necessary to support a security mechansim. It would be much less   confusing, and easier to specify, if there is one credentials    object per mechanism.      We should state that one credential object supports one   mechanism type.       

Summary:       Each security context, at least at the SECIOP/GIOP levels each   have a client and target orientation. This is not reflected   in the SecurityContext interface.      Also, using the same context for both, is misleading, in the   sense that "received_credentials" does not make sense for   a context on the client side:    

Summary: It would appear since the SecurityContext must hold onto the   Credentials object, that the Credentials object must appear   in SecurityReplaceable as well, since there is no factory   for generation of credentials in an independant way.      Perhaps a "Server Context should have a list of   security attributes instead of a list of credentials.   That way an orb using a replacable module can create a local   credentials object and put the security attributes in it.       

Summary: As I lamented before. I fear that to make much implemenation   sense out of the "replaceability of the module I believe    SecurityReplaceable should have Credentials and PrincipalAuthenticator   as well.      Note: This does not proclude security level 2 from having   Credentials and PrincpalAuthenticator, just that SecurityReplaceable   should have them as well.   .    

Summary: Okay, I"ll give you there is a need for security features   provided they are only looked at for supported features of   credentials and contexts. Not for setting.   These should be done via setting assoication options and setting the    delegation mode;      To simplfy the semantics of SecurityFeatures and using them,   the spec should specify a good programing model. Otherwise,   examining them and manipulating them becomes ineffcient.          

Summary: Using SecurityOpaque causes needless buffer copying. I suggest   a buffer interface.   Using a sequence<octet> for tokens going in and out of    SecurityReplaceable::Vault and SecurityContext imply   (at least in the Java) maps it to an array of fixed length.      This causes the implementations to constantly recopy entire    arrays just to get the length attribute set correctly.    

Summary: The model currently specifies that _set_policy_overrides(), and    get_policy() apply to the particular object reference.      That would mean that the policies applied to accessing Current.   I suggest that we aliviate this discrepancy by putting a   CORBA::PolicyManager get_policy_manager() on the Current interface.   The PolicyManager is currently part of the new Async Messaging Specification   and would be a good interface to do this with.    

Summary: I"m having real problems trying to interpret the specification on the   own_credentials list.   I"m working from the Security Spec 1.2, 5 Jan 1998    It seems to be implied by paragraph 4 of 15.5.4.1 Description of   Facilities on page 15-87, which says:      Credential objects are created as a result of:      o Authentication (see Section 15.5.3,  "Authentication of Principals", on     page 15-85.   o Copying an existing Credentials Object   o Asking for a Credentials object via Current (see Section 15.5.6,      "Security Operations on Current" on page 15-97).      and, by paragraph 7 of section 15.5.6.3 SecurityLevel2::Current   Interface:      own_credentials      Any application owns a set of credentials which it obtains through the   process of authentication of the principal that initiates the execution of   the program, and further from other credentials that such a principal   might bestow upon the application. This attribute returns this set of   credentials.          Okay, so the problem is that these statements imply, but do not explicitly   stipulate that the PrincipalAuthenticator puts Credentials objects on the   "own_credentials" list.        

Summary: Inconsistent definitions of whether own_credentials is thread            specific, object specific (?), or application/process/capsule            specific.       

Need specific way to associated credentials with            the target object reference on the target side.

:Opaque because the C++ mapping causes a new object to 

Summary: SecurityCurrent should probably inherit from PolicyCurrent to marry this   functionality of dealing with policies. However, the messaging   specification I don"t think is "adopted", although it has an RTF. I don"t   know what is the proper procedure about RTFing things on not-yet adopted   technology.   The PolicyManager has a serious, or at least I   think it"s serious flaw. The PolicyManager has "get_policy_overrides" and   "set_policy_overrides" functions. So does CORBA::Object.  However, the   problem is. Not only do these operations on PolicyManager have different   semantics than the corresponding ones on CORBA::Object,   "set_policy_overrides" has a different signature!    

Summary: Policies in SecurityAdmin are unclear in their interpretations. It is   clear from discussions we have had in the group, that too many different   interpretations can ensue.          This is a problem with trying to define security policy in IDL. There   should be a minimum interface that may be supported that will allow a   language description to be taken as an argument, that will define the   policy for the policy object. The query interfaces may be the same.       

Summary: The CORBASecurity spec. uses three different datatypes for interfaces:       InterfaceDef    RepositoryID    Identifier      InterfaceDef should definitely NOT be used, as it can"t be resolved without   reference to the   Interface Repository, which would be a big performance penalty for cases where   the interface"s   name is simply being matched or used as a lookup key in a local table.      Identifier is also the wrong type; it"s a generic string type and hence not   type-safe with respect   to interface names.    

Summary: I think we have a further problem representing the received   credentials from the server.      We have more than just two attributes on received credentials   which are more suited to the nature of a client, as opposed   to a server/target.  We have      readonly attribute Credentials     accepting_credentials;   readonly Security::DelegationState delegation_state;   readonly attribute Security::DelegationMode delegation_mode;   readonly attribute Security::AssociationOptions   				association_options_used;      What do we do about delegation_state or delegation_mode   for received credentials from the server?    

Certain parameters of locality constrained interfaces were using  "sequence octet" due to the inherent fear of CORBA any's. This should not  be a problem. Also it is a serious bug as this might requires unnecessary  marshalling of data to pass into the operations of locality constrained  objects.    The interfaces, their operations and parameters that are affected follow:    PrincipalAuthenticator  	authenticate  		auth_data,continuation_data,auth_specific_data  	continue_authentication  		response_data,continuation_data,auth_specific_data  AuditDecision  	audit_write  		event_specific_data  Vault  	acquire_credentials  		auth_data,continuation_data,auth_specific_data  	continue_acquisition  		response_data,continuation_data,auth_specific_data    These parameters should have the type "any".

  "sequence<octet>"

The RequiredRights are confusing. (Issue raised within the RTF itself).    The Rights combinators SecAllRights and SecAnyRights are underspecified.  The notes on the implemenations of Required Rights are confusing.  

The Security Replaceablity interfaces are deficient in the aspect of  creating the correct components for the IIOP profile of the IOR for the  specified credentials.    The Vault::init_security_context, takes a parameter, mech_data, which is  the data component of the tagged component that was selected by the ORB  from the IOR for which the mechanism that was used in starting the secure  association.    However, analogously on the accepting side, there is no way to create a  tagged component for use in the IOR! Adding functionality to the vault  will complete the security replaceablity and fill this hole.    I suggest to *add* the following definitions to Security Replaceable.      #include <IOP.idl>      typedef sequence<IOP:TaggedComponent> TaggedComponentList;        interface Vault {      TaggedComponentList create_iiop_components(  	in SecurityLevel2::CredentialsList     creds_list      );    };    The Vault produces the correct IOP tagged components for the set of  credentials specified that will be placed in the IIOP profile.     There is no definite 1 to 1 correlation between the credentials in the  given list and the tagged components generated. The vault may determine  that some credentials are redundant, irrelevant, or take precedence over  other credentials.  

Subject: There is no way to find out how Tagged Components are           generated for replaceable security mechanisms. This  	should be a function of the Vault, as it is the   	center piece of security mechanism replaceablablity.    

Subject:  Need MechanismType identifier for TAG_GENERIC_SEC_MECH            components.  Discussion:    Mechanism Type identifier is said to be constructed by the IOR's tagged  component identifier. However, under the current specification, all  mechanisms represented by the TAG_GENERIC_SEC_MECH still need to be  further distinguished by their security_mechanism_type identifier.

References 19, Simple GSS Negoiation  Reference  20, Simple Public Key Mechanism    are web pointers, non-existant and need to be updated.  RFC numbers exist for these, specifically RFC2478, and RFC2025  respectively.  

There is a requirement to pass a sequence of IOP::TaggedComponents between  interfaces of different modules, namely SecurityReplaceable and Portable  Interceptors.     We would like to see a typedef in module IOP of:    module IOP {      typedef sequence<TaggedComponent> TaggedComponentList;  };    Due to different language mappings and the way they handle typdefs, a  definition in a common place is needed instead of having each module  define their own typedef for a sequence<IOP::TaggedComponent> as this  approach would provide for a difficult hand-off for the type.   

I wanted to raise some issues with the firewall report (Firewall RTF)  related to SOCKS and IOR's.    1. If information is required for authentication with the socks server then  there is no direction given on how to get this. The solution should not be  pop up a dialog because server programs would hang. It would be nice to have  some kind of callback to the orb clients that could request password. Then  the client could decide to throw an error or pop up a dialog box.   

2. The other problem I could see was related to adding firewall info to the  IOR. If a client makes a call to a server thru a firewall(s) and the server  returns (1.0) IOR's then those IOR's should have the firewall information  added to them. The other problem is that if the client calls the server and  passes an IOR with firewall info in it then there are other issues, for  example    	- The IOR passed has the same firewall info as the IOR of the  objects being called. In this case the server should strip off the firewall  information in order to use the IOR.  	- The IOR passed has different firewall info than the IOR of the  objects being called. In this case the server should keep the firewall info.    This implies that the marshalling and unmarshalling code should add/remove  firewall info to IOR depending on the firewall information of the objects  IOR.   

CORBA Security SECIOP.      In SECIOP, one RTF changed a field in the SECIOP Message Header  from          struct ulonglong {              unsigned long low;              unsigned long high;      };          // This should be changed to unsigned long long      typedef ulonglong ContextId;      to          typedef unsigned long long ContextId;      because of the introduction of the long long type into CORBA.      This modification changes the specification the CDR encoding of the  structure, because what was compact 8 byte sequence aligned on a 4 byte  boundary. now became an 8 byte sequence aligned on an 8 byte boundary.      Each SECIOP message is preceded with a GIOP Message header, which is 12  bytes. Each SECIOP message, which is specified by a struct, starts with  the ContextId. Strict interpretation of the encoding rules makes the  SECIOP messages incompatiable, as the space between the header and the  message must now contain 4 bytes padding.      Proposed Resolution: revert back to the struct ulonglong definition.  

The SECIOP State machine has a problem with Discard context. The  specification currently specifies that if either side sends a Discard  Context, the context is discarded on both sides immediately. Therefore, a  client must wait to send a Discard context considering all messages sent  until it can figure out if all expected messages are received.      This situation causes too much coordination between the upper ORB layers  and the lower transport layers in SECIOP. The SECIOP state machine must be  knowledgeable about requests and whether they expect a repose. Then the  SECIOP message layer must know about GIOP message structures.      The proposed way to do this is when a Discard context is sent, it says  that no more data will be sent in that direction. The peer must respond in  kind with a Discard Context message when all data is sent back. Then the  context shall be closed.