Security Service Avatar
  1. OMG Specification

Security Service — Open Issues

  • Acronym: SEC
  • Issues Count: 36
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SEC14-50 SECIOP ContextId SEC 1.4 open
SEC14-49 Adding firewall info to the IOR SEC 1.4 open
SEC14-44 Section: 15.7 Security Implementers Interfaces. SEC 1.4 open
SEC14-43 Security: Need to complete SecurityReplaceable SEC 1.4 open
SEC14-48 Firewall issue regarding SOCKS SEC 1.4 open
SEC14-47 Need TaggedComponentList typedef. SEC 1.4 open
SEC14-42 The RequiredRights are confusing SEC 1.4 open
SEC14-41 Parameters of locality constrained interfaces were using "sequence octet" SEC 1.4 open
SEC14-46 Section: Appendix I: Dangeling References SEC 1.4 open
SEC14-45 Section: 15.8.14 CORBA Interface SEC 1.4 open
SEC14-51 SECIOP State Machine Discard SEC 1.4 open
SEC14-40 $issue.summary SEC 1.4 open
SEC14-39 $issue.summary SEC 1.4 open
SEC14-38 $issue.summary SEC 1.4 open
SEC14-37 $issue.summary SEC 1.4 open
SEC14-17 Inconsistency between IDL and spec SEC 1.4 open
SEC14-16 own-cedentials model SEC 1.4 open
SEC14-19 CORBA::PolicyManager SEC 1.4 open
SEC14-18 Construction Policy SEC 1.4 open
SEC14-21 Interfaces are specified using wrong datatype in CORBASEC SEC 1.4 open
SEC14-20 SecurityAdmin Policies SEC 1.4 open
SEC14-23 $issue.summary SEC 1.4 open
SEC14-22 ReceivedCredentials. SEC 1.4 open
SEC14-36 $issue.summary SEC 1.4 open
SEC14-35 $issue.summary SEC 1.4 open
SEC14-32 $issue.summary SEC 1.4 open
SEC14-31 $issue.summary SEC 1.4 open
SEC14-25 $issue.summary SEC 1.4 open
SEC14-24 $issue.summary SEC 1.4 open
SEC14-27 $issue.summary SEC 1.4 open
SEC14-26 $issue.summary SEC 1.4 open
SEC14-34 $issue.summary SEC 1.4 open
SEC14-33 $issue.summary SEC 1.4 open
SEC14-29 $issue.summary SEC 1.4 open
SEC14-28 $issue.summary SEC 1.4 open
SEC14-30 $issue.summary SEC 1.4 open

Issues Descriptions

SECIOP ContextId

  • Key: SEC14-50
  • Legacy Issue Number: 5526
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Fri, 19 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Adding firewall info to the IOR

  • Key: SEC14-49
  • Legacy Issue Number: 3407
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: SEC 1.4 — Fri, 3 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.7 Security Implementers Interfaces.

  • Key: SEC14-44
  • Legacy Issue Number: 3044
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Mon, 22 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Security: Need to complete SecurityReplaceable

  • Key: SEC14-43
  • Legacy Issue Number: 2958
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Tue, 26 Oct 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Firewall issue regarding SOCKS

  • Key: SEC14-48
  • Legacy Issue Number: 3406
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: SEC 1.4 — Fri, 3 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need TaggedComponentList typedef.

  • Key: SEC14-47
  • Legacy Issue Number: 3047
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Wed, 24 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The RequiredRights are confusing

  • Key: SEC14-42
  • Legacy Issue Number: 2928
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Mon, 4 Oct 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameters of locality constrained interfaces were using "sequence octet"

  • Key: SEC14-41
  • Legacy Issue Number: 2927
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    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".

  • Reported: SEC 1.4 — Mon, 4 Oct 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix I: Dangeling References

  • Key: SEC14-46
  • Legacy Issue Number: 3046
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Mon, 22 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.8.14 CORBA Interface

  • Key: SEC14-45
  • Legacy Issue Number: 3045
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Mon, 22 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

SECIOP State Machine Discard

  • Key: SEC14-51
  • Legacy Issue Number: 5527
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    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.

  • Reported: SEC 1.4 — Fri, 19 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-40
  • Legacy Issue Number: 2736
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Mon, 14 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-39
  • Legacy Issue Number: 2735
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Mon, 14 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-38
  • Legacy Issue Number: 2734
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Mon, 14 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-37
  • Legacy Issue Number: 2733
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Mon, 14 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency between IDL and spec

  • Key: SEC14-17
  • Legacy Issue Number: 2030
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.4 — Fri, 2 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

own-cedentials model

  • Key: SEC14-16
  • Legacy Issue Number: 2028
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: SEC 1.4 — Fri, 2 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::PolicyManager

  • Key: SEC14-19
  • Legacy Issue Number: 2069
  • Status: open  
  • Source: Anonymous
  • Summary:

    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!

  • Reported: SEC 1.4 — Fri, 9 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Construction Policy

  • Key: SEC14-18
  • Legacy Issue Number: 2033
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: SEC 1.4 — Mon, 5 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interfaces are specified using wrong datatype in CORBASEC

  • Key: SEC14-21
  • Legacy Issue Number: 2201
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: SEC 1.4 — Tue, 10 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

SecurityAdmin Policies

  • Key: SEC14-20
  • Legacy Issue Number: 2086
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: SEC 1.4 — Thu, 15 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-23
  • Legacy Issue Number: 2707
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Wed, 9 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReceivedCredentials.

  • Key: SEC14-22
  • Legacy Issue Number: 2558
  • Status: open  
  • Source: Anonymous
  • Summary:

    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?

  • Reported: SEC 1.4 — Mon, 29 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-36
  • Legacy Issue Number: 2732
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Mon, 14 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-35
  • Legacy Issue Number: 2724
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Thu, 10 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-32
  • Legacy Issue Number: 2720
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Thu, 10 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-31
  • Legacy Issue Number: 2719
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Wed, 9 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-25
  • Legacy Issue Number: 2710
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Wed, 9 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-24
  • Legacy Issue Number: 2709
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Tue, 8 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-27
  • Legacy Issue Number: 2715
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Tue, 8 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-26
  • Legacy Issue Number: 2711
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Wed, 9 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-34
  • Legacy Issue Number: 2723
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Thu, 10 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-33
  • Legacy Issue Number: 2722
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Thu, 10 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-29
  • Legacy Issue Number: 2717
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Wed, 9 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-28
  • Legacy Issue Number: 2716
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Wed, 9 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: SEC14-30
  • Legacy Issue Number: 2718
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: SEC 1.4 — Thu, 10 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT