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

Issue 357: The generate_token and verify_evidence methods have problems
Issue 371:
Issue 374: How does get_effective_rights get the delegation state?
Issue 998: AccessPolicy can"t distinguish intiator and delegates
Issue 1404: Typo in 98-01-02
Issue 1756: Semantics of the Mechanism Policy is not defined wel
Issue 1757: Operations regarding Security Features
Issue 1758: Inconsistent Spelling between Security and SecurityLevel2
Issue 1759: Misspelling
Issue 1760: Duplicate DelegationMode(s) in Security and SecurityLevel2
Issue 1761: DelegationDirectivePolicy Needed
Issue 1763: Credentials issue
Issue 1764: Security Context does not reveal client/server orientation.
Issue 1766: Credentials not in SecurityReplaceable.
Issue 1767: Credentials and PrincipalAuthenticator should be in SecurityReplaceable
Issue 1768: SecurityFeatures still confusing!
Issue 1786: Using SecurityOpaque causes needless buffer copying
Issue 1787: Current:get_policy() is semanitically insconsitent with curr. object mode
Issue 2028: own-cedentials model
Issue 2030: Inconsistency between IDL and spec
Issue 2033: Construction Policy
Issue 2069: CORBA::PolicyManager
Issue 2086: SecurityAdmin Policies
Issue 2201: Interfaces are specified using wrong datatype in CORBASEC
Issue 2558: ReceivedCredentials.
Issue 2707:
Issue 2709:
Issue 2710:
Issue 2711:
Issue 2715:
Issue 2716:
Issue 2717:
Issue 2718:
Issue 2719:
Issue 2720:
Issue 2722:
Issue 2723:
Issue 2724:
Issue 2732:
Issue 2733:
Issue 2734:
Issue 2735:
Issue 2736:
Issue 2927: Parameters of locality constrained interfaces were using "sequence octet"
Issue 2928: The RequiredRights are confusing
Issue 2958: Security: Need to complete SecurityReplaceable
Issue 3044: Section: 15.7 Security Implementers Interfaces.
Issue 3045: Section: 15.8.14 CORBA Interface
Issue 3046: Section: Appendix I: Dangeling References
Issue 3047: Need TaggedComponentList typedef.
Issue 3406: Firewall issue regarding SOCKS
Issue 3407: Adding firewall info to the IOR
Issue 5526: SECIOP ContextId
Issue 5527: SECIOP State Machine Discard

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.