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 138: Message Level Interceptors
Issue 151: Current object question
Issue 152: SecurityLevel2::Object
Issue 180: CORBASEC IDL files in Appendix A
Issue 282: Message Level interceptors
Issue 307: Service Context ID Assignment (scenario 1)
Issue 308: Service Context ID Assignment (scenario 2)
Issue 337: Provide a "day_of_week" audit event selector
Issue 338: Clarify language on Non-Repudiation delivery authority
Issue 339: Provide message identification information
Issue 340: Improve description of secure invocation policy rationalization
Issue 341: get_security_names issue
Issue 342: SECIOP servers cannot contact SECIOP clients
Issue 343: SECIOP protocol definition
Issue 344: SECIOP conformant server timed out
Issue 345: Definition of MessageInContext needs to be cleared
Issue 346: Missing explanation of the use of MessageInContext message
Issue 347: QOP discovered in SecurityContext
Issue 348: Intermediate objects
Issue 349: How do I get to a specific binding while making an invokation?
Issue 350: set_privileges adequate?
Issue 351: Clarify what creating object is
Issue 352: What Security policy Domain during BOA::create?
Issue 353: Meaning of "as specified object"
Issue 354: Is it intent of specification to only secure BOAs?
Issue 355: Use of NoDelegation is inconsistent with terms used on p 44
Issue 356: Is enum EvidenceType intended to be a complete list?
Issue 358: make_domain_manager issue
Issue 359: Which interface apply RequiredRights to
Issue 360: Inheritance not properly accounted in audit operation parameters
Issue 361: What does DetectMisordering mean for a multithreaded process?
Issue 362: Capabilities is under defined
Issue 363: Definition of identity domains confusing
Issue 364: User Sponsor section should be rewritten
Issue 365: Editorial change
Issue 366: AssociationOption
Issue 367: get_domain_policy
Issue 368: What does "-" mean in "corba::-g"?
Issue 369: Initiator is undefined on pg 145
Issue 370: Current object needs further specification
Issue 372: DomainAccessPolicy incorrectly inherits from CORBA
Issue 373: Why do DomainAccessPolicy set methods have family arguments?
Issue 375: How do add/delete RequiredRights interface entries?
Issue 376: What if there are no attribute mappings in a policy?
Issue 377: What does get_audit_selectors return?
Issue 378: Does AuditPolicy use an implicit ALL combinator?
Issue 379: When is the "ObjectRef" selector type used?
Issue 381: SecurityLevel2::Object needs further specification
Issue 475: Credentials object underspecified
Issue 487: Missing IDL in Appendix A
Issue 534: Life cycle of Policy object is not specified
Issue 536: Current and get_current()
Issue 537: Insufficient specification of Exceptions
Issue 538: Inappropriate use of the word interface
Issue 539: IDL in text needs fully qualified names
Issue 544: SSL Protocol
Issue 552: Constant values for ServiceOptions (Section B.9.1)
Issue 553: PolicyType declared as enum (section B.9.2)
Issue 554: Policy types defined in B.9.2 pertain to Security
Issue 555: Policy Object
Issue 630: Access to AccessDecision and AuditDecision objects?
Issue 634: Credentials in Security rev 1.2 are inconsistent
Issue 635: Const declarations missing for audit event types?
Issue 649: Problems related to "locally constrained" of Credentials (1)
Issue 650: Problems related to "local constrainedness" of Cresentials (2)
Issue 661: Typo on page 6 of SSL spec (orbos/97-02-04)
Issue 712: DomainAccessPolicy operation question
Issue 713: Tag value of TAG_SSL_SEC_TRANS
Issue 714: SSL/CORBA-How does client choose to use SSL?
Issue 716: RequiredRights
Issue 717: Exceptions to be thrown by (administrative) operations
Issue 718: SSL/CORBA-How does client choose to use SSL?
Issue 720: Object side-effect semantics
Issue 972: Typo in spec and IDL text
Issue 1633: Paragraph 19, section 15.8.4.2
Issue 1661: Extension to SecurityContext to support SECIOP::DiscardContext
Issue 1723: SecIOP Architecture
Issue 1765: Credentails.set_privileges()
Issue 1847: Principal Authenticator
Issue 1930: DelegationMode
Issue 2027: PrincipalAuthenticator and Current
Issue 2094: get_security_names
Issue 2122: Typo in 15.7.1.1, p.15-145, very last bullet:
Issue 2161: SecurityLevel2::Current policy factory operation
Issue 2169: Table description incorrect in Security Service
Issue 2170: SecurityAdmin::DomainAccessPolicy::grant_rights takes SecAttribute
Issue 2199: Table 15-25 Attribute Values lists family 0 attributes as family 1
Issue 2259: del parameter of set_delegation should be Security::DelegationDirective
Issue 2260: accept_security_contect() creds parameter
Issue 2344: More nil/NULL arguments that need to be removed
Issue 2437: Security: SECIOP
Issue 2440: Need to get Received Credentials from the Server
Issue 2451: Channel Bindings are underspecified
Issue 2452: Inappropriate examples of Integrity Violations
Issue 2703: How is a SecAttribute"s value field encoded
Issue 2704: Capule Specific items residing on thread specific Current
Issue 2708: Which codeset is used in CDR encoding (interop)
Issue 2789: Security: SSL reference no longer valid
Issue 2800: Public Attribute extraneous and inefficient
Issue 3262: Regarding Principal Authenticator in security/99-12-02
Issue 3272: SECIOP Sequencing Layer is superfluous and redundant
Issue 3442: editorial revisions to address issue #1765 were not completed correctly
Issue 3571: AuditChannel::audit_write has Opaque
Issue 3572: SecurityContext::process_context_token
Issue 3577: No Standard Authentication Mechanism Specification for Kerberos
Issue 3591: URL format for IIOP-SSL
Issue 3620: Differ by case IDL error in "Right" structure Security module
Issue 3629: SecurityReplaceable module errors in Security spec 1.7
Issue 3630: CCM spec and Security Service 1.7 do not agree
Issue 3638: Fix description of parameters to Credentials::set_attributes
Issue 3765: Inconsistency in security service spec

Issue 138: Message Level Interceptors (sec-rev)

Summary: Where is the parameter of type Message defined, other than the PIDL?

Summary: Is the Current object intended to be a pseudo-object or a real object? If it"s a pseudo-object, how does the programmer narrow a CORBA::Current returned by ORB::get_current()?

Summary: In a SecurityLevel2 compliant ORB, can any object be narrowed to a SecurityLevel2:Object in order to access the additional operations?

Summary: IOP and TimeBase modules are onle referenced in OMG CORBASEC, Security::SelectorSequence not defined in Security module IDL file, synyax error

Summary: In CORBASEC the two methods in MessageInterceptor interface are shown as taking an parameter of type Message. Where is this type defined?

Summary: CORBA spec sec 10.6.6 Object Service Context. We need to flow service context information for propietary services. IDs should be assigned by OMG. Prevents conflicts with future OMGassignments

Summary: Need to flow Security context information and would like to have a service context ID assigned. We need flow security contexts over IIOP.

Summary: Provide a "day_of week" audit event selector

Summary: Clarify language on Non-Repudiation delivery authority. What is supported by the specification?

Summary: [Provide message identification information sufficient to determine which security context was used to protect MessageInContext

We agreed to just close this issue since protection information
is not quite tied to the message, but the transport of the
message, i.e. SECIOP, SSL, etc.

Summary: Improve description of secure invocation policy rationalization

Summary: get_security_names should be able to return the mutually authenticated "identity" (??) of an object. It should have option indicating whether caller wants all supported security names.

Summary: SECIOP servers cannot contact SECIOP clients in order to send DiscardContext messages since clients are not listening on TCP ports to receive such messages

Summary: The SECIOP protocol definition is ambiguous about the meaning of a DiscardContext message received by a client. not specified whether server lost context before/after processing message

Summary: A SECIOP conformant server whose context has timed out may send a DiscardContext message in response to a client"s IIOP CancelRequest or MessageError message in unpredictable way

Summary: Ran across an ambiguity in definition of MessageInContext that needs to be cleared up. Is length of this "higher level" message included? It should be.

Summary: What may be missing from text is that if reply or reply fgragment is available to be sent whe complete_establish_context message is returned to client mesaage must be sent with MessageInContext.

Summary: SecurityContext::reclaim_message uses length of supplied token as IMPLICIT parameterindicating QOP which was applied to the supplied message. Carried differently in SECIOP protocol.

Summary: For delegation, it is assumed that the "intermediate object" is in fact a single object. What we want is to be able to construct an object that uses other objects in its implementation

 closed issue

Summary: Binding stuff is still a problem.Current object, or something in it will be used during a call to select binding. There may be several bindings that are concurrently available for an object

 closed issue

Summary: set_privileges says "restricted to ones this principal is permitted to have." Is this adequate? Principals have several identities and privilege attributes Weren"t they restricted?

Summary: Application object calls BOA::create to create new object reference. ORB gets construction policy associated with the creating object. There is no application or creating object>

Summary: When I asked how to write a portable application, I was pointed at page 91. I don"t see how it works. What Security Policy Domain is associated with new object during BOA::create?

 closed issue

Summary: What does the "as specified object" mean in "The construction policy controls whether a new domain is needed as well as the specified object."?

Summary: Section deals with the BOA. Is it the intent of the spec to only have secure BOA objects or may other OAs have secure objects? There should be some words about non-BOA OAs either hereor App: G

Summary: Discussion on top of page is inconsistent with terms used on p.44 NoDelegation is used to select which credentials. This is either reusing same term differently (wrong) or inconsistent with use p44

Summary: If it is not intended to be a complete list, then the normal way to do this is to have a value with "const" for the known values, reserving range, having range for applications

Summary: make_domain_manager forces the default to be making a new domain manager for every new instance of this interface. There is no inverse operation. Adding a boolean for enable/disable?

Summary: Clarify which interface the RequiredRights apply to in a chain of derived interfaces. I missed that RequiredRights can be changed dynamically

Summary: I do not think inheritance has been acounted for properly in the audit operation parameters.

Summary: DetectMisordering: What does this mean for a multithreaded process calling another multithreaded process? Is it meaningful?

Summary: capabilities is under defined. This term is used in various ways so it should be crisply defined. Text in section 3.5.3 could be expanded.

Summary: "Identity domains: these are domains where objects can share a security identity as objects in the same identity domain." HUH??

Summary: I recommend that the User Sponsor section be rewritten. It does not adequqtely *define* the User Sponsor. It talks about the User Sponsor.

Summary: "as at the client". I find the mixing up of what the client sees as current obscures the meaning of this.Last para of the section mixes up clients and servers.

Summary: The const"s for AssociationOption are powers of two, but the only use of AssociationOption are in the sequence AssociationOptions.  Presence of sequence AssociationOptions was a bug. Was removed.

Summary: The get_domain_policy returns a Policy yet the comment says "get policies for objects...". It"s just a little bit confusing to read plural where the singular is intended.

Summary: What does "-" mean in "corba:g-"? If it means "doesn"t have s" then why isn"t there a "-" for m?

Summary: p 145: "initiator" is undefined. It could mean the immediate parent in the call chain, or the top of the call chain

Summary: Is current object intended to be pseudo object or real object? If pseude object, how does programmer narrow a CORBA::Current returned by ORB::get_current()to SecurityLevel::current?

Summary: IDL on p225 [15-205] doesn"t inherit from AccessPolicy (disagrees with p150 [15-132] description)

Summary: Set methods of DAP have ExtensibleFamily and Rightslist arguments. Rights datacontains family values already? Description on p150/151 doesn"t mention rights_family arguments.

Summary: There is only a single set_required_rights method on the RR interface in contrast to rich grant/revoke/replace set on DomAccPolicy and AuditPolicy. Should set add entries?

We agreed to close this issue because the get/set methods
are sufficient. The functionality being looked for in this issue
is more suited to a value-added library use of the get/set
functions.

Summary: Mapping Attributes to rights: what should happen if a given right in the Credentials doesn"t have a mapped right? Eithe fail the get_effective_rights or ignore it. The latter sounds better..

Summary: Shouldn"t this just operate on a single event type? I could return all selector values for all event types. but how would caller distinguish which ones were set for which event?

Summary: AuditPolicy audit_needed only returns OK if selector values passed in match All. the values set in policy. Doesn"t have ANY/ALL combinator flexibility of RequiredRights. Too rigid?

Summary: Section 6.6.1: Object selector type isn"t something that would be stored in policy. It would be better to have Object as a seperate argument rather than to call it a selector type.

Summary: How about SecurityLevel2::Object? Can any object be narrowed to be a SecurityLevel2:Object in order to access additional operations in a SecurityLevel2 compliant ORB?

Summary: Lifecycle of Credentials object isn"t clearly specified in CORBAsecurity spec rev 1.1 , e.g when can they be safely destroyed, who is responsible for such an act?

Summary: IDL for the accept_security_context () method in the Vault interface is missing the Security Context output, as described in section 15.7.4.

Summary: The issue of absence of a specification of life cycle of Policy object is going to be addressed and resolved by RTF

Summary: Security spec uses CORBA::Current, while our (transactions?) spec says CORBA::ORB::Current. Anybody involved in all 3 (CosTx, CosSec,Core)to make sure inconsistency gets cleared-up?

Summary: Explanations associated with many operations allude to fact that they raise standard exceptions without elicidating on circumstances under which such exceptions are raised.

Summary: In many places in the security specification that word interface is used to refer to things that OMA would call operations. This should be fixed

Summary: IDL presented within the text contains unqualified names of types and interfaces..makes it hard to read and place within overall context of various modules constituting Sec spec IDL specification

Summary: For interop it is essential that clients connecting to SSL-secure servers know when and how to execute SSL handshake. One submission does not mention when SSL handshake occurs.

Summary: Constant values for ServiceOptions defined pertain to Security Service, have nothing to do with core ORB. Move them from CORBA module to the Security module.

Summary: PolicyType is declared as enum thus making it not easy to extend. Define it as "unsigned long", and then define the various PolicyTypes as const values

Summary: Is there a problem in moving the const declarations out of CORBA module and into Security module?

Summary: GIven a Policy object there is no way of telling what PolicyType it is of. Add " readonly attribute PolicyType policy_type; " to the Policy Interface.

Summary: How does user application get hold of object references to AccessDecision and the AuditDecision object? Spec does not provide any means for poor application to get access

Summary: Section 15.5.4[2], 15.5.3[3], 15.5.7[12]: what was meant is that Credential cannot be exported to non-security service object, can only be imported to client.

Summary: A.9.3 specifies series of System audit events. Should these have declarations in Security.idl or can these be assigned any values. For consistency I am leaning toward the former

Summary: In interface SecurityAdmin::AccessPolicy, operation get_effective_rights which passes in an argument of type CredentialsList

Summary: In interface SecurityLevel2::AuditChannel operation audit_write, which has CredentialsList parameter. If problem is fixed, it appears in SecurityAdmin::AuditPolicy operation set_audit_channel

Summary: There is a typo on page six of the SSL spec (orbos/97-02-04). Both occurences of "traget" should be changed to "target"

Summary: We are not clear on meaning of rights_family argument to operations grant_rights, revoke_rights, replace_rights. How is the additional argument used?

Summary: In the RFP submission, SSL/CORBA Security (orbos/97-02-04), the mechanism TAG, TAG_SSL_SEC_TRANS, was not given a tag value. It"s not defined in CORBA V2.1 either

Summary: What criteria does does client use when choosing to use SSL?Was intent for AssociationOption, target_requires to be only determining factor for client decision to use SSL?

We agreed to close this issue because the current state
of the specification (RTF 1.5) allows for this capability.

Summary: get_required_rights takes target objref as argument. The set_required_rights takes no such argument. Does spec address the correlation of required_rights to actual targets?

Summary: DomainAccessPolicy operation revoke_rights doesn"t specify exceptions to be thrown in case "no rights granted for that attribute"and in to-be-revoked RightsList for some/all rights

Summary: Was intent for the AssociationOption, target_requires, to be the only determining factor for the client to use when making the decision to use SSL? (orbos/97-02-04 1st sentence, last para, p.6)

Summary: I am confused about semantics of the side-effecting override_default_* operations on CORBA::Objects. Are these overrides attached to the reference or to the destination?

Summary: also - both the spec and the idl text have a typo in the very first
 > line of the Security module spec... where is says:
 > 
 >             typedef string security_name;
 > 
 > it should say:
 > 
 >             typedef string SecurityName;
 

Summary: Paragraph 19 of section 15.8.4.2 says:
 
 "In this example if mechanism “mech 1” is used the target security name is “MBn1”
 while the association must use integrity replay and misordering options. If mechanism
 “mech 2” is used no mechanism specific security name has been specified and so
 “Manchester branch” is used as the security name. The association options are
 EstablishTrustInClient and Integrity."
 
 The last sentence seems to imply that if "mech 2" is used the top-level 
 association options, and not the association options for "mech 2" are used.
 If this is always the case, then it would seem pointless to bother 
 specifying association options for "mech 2" because they will never be 
 used.  If this is the case (which would also be very strange) only when 
 a tag_sec_name is not present for "mech 2" this should be explained 
 more clearly.
 

Close issue 1633: Paragraph 19, section 15.8.4.2
Reason: We agreed to close this issue because it is the same issue
as issue 714.

Summary: I believe the SecurityContext interface needs to be extended to properly
 support the SECIOP::DiscardContext message.
 

 received issue

Summary: In trying to understand some problems we"re having on
 our reference implementation development, I"ve run 
 across an inconsistency in the CORBAsec V1.2 spec.
 
 On page 15-191, Section, 15.9.1, there is a figure
 15-59 that shows the SECIOP protocol underneath the
 IIOP protocol.  This is contrary to my understanding 
 of the SECIOP architecture, which corresponds to
 Figure 15-57 - where the SECIOP protocol is located 
 between the GIOP and IIOP protocols.
 
 Hopefully, the problem is simply that Figure 15-59
 should have "IIOP" replaced by "GIOP".
 
 
 

Summary: The documentation states that the force_commit parameter given the value
 of false will cause the privileges to be set at a later time. If so,
 what does the out parameter "actual_privileges" return?
 Is this valid only if force_commit was true and successful?
 
 Also, boolean states a return value. I believe this should be
 void, and state that exceptions will be raised with reasons for
 failure.
 
 
 

Summary: Security 1.3 Service pages 15-87 5 Jan 1998
 
 continue_authentication has the wrong in/out designations on 
 three of its four parameters.  I have in, in, out, out.
 
 It shoud be
 
 continue_authentication(
   in    Opapue      response_data,
   inout Credentials creds,
   inout Opaque      continuation_data,
   inout Opaque      auth_specific_data
 );
 

Summary: enum DelegationMode is defined in Security.idl and in SecurityLevel2.idl.
 Both definitions are rather different:
 

 received issue

Summary: I have a problem discovering the semantics of using
 Current.set_credentials(SecInvocationCredentials) as opposed to using an
 InvocationCredentials Policy object on Current, or the target object
 reference.
 
 I believe we should deprecate set_credentials and get_credentials infavor
 of InvocationCredentials and NonRepudiationCredentials Policy Objects.
 This mechanism seems more in line with the the way we seem to be
 traveling. So it will be consistent with the client invocation policy
 model. 
 
 Or. we should put an explicit statement ordering the retrieval of
 credentials at object reference creation. 
 
 1. InvocationCredentailsPolicy object off of Target object reference.
 2. InvocationCredentialsPolicy object from the Current.
 3. Current.get_credentials()
 

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.
 

:MechandOptions struct only contains options

Summary: In 15.7.1.1, p.15-145, very last bullet:
 SecureInvocationPolicy::get_delegation_mode should be
 DelegationPolicy::get_delegation_mode.
 

Summary: 
 The Policy factory operations in SecurityLevel2::Current should be
 deprecated and the ORB::create_policy operation should be used for
 creating QOPPolicy, MechanismsPolicy, InvocationCredentialsPolicy
 instead.
 

 Security RTF 1.5 action 7 in ptc/98-11-0

Summary: Table 15-7 has the title "Domain Access Policy (with Required Rights
 Mapping)".  The "(with Required Rights Mapping)" part should be
 removed since it doesn"t include the required rights.
 

Summary: On p. 15-140 of security/98-10-01, the description of grant_rights
 says the first parameter is Attribute.  The first parameter should be
 SecAttribute.
 
 

Summary: I think its a formatting problem rather than a type-o.  The "Privilege
 Attribute (family = 1)" heading looks like it was automagically copied
 to the first row of the table when the table cross a page break.
 

Summary: t is possible that in
 the final resolutions document we forgot to say that the type of the
 "del" parameter of set_delegation should be
 Security::DelegationDirective and not SecurityLevel2::DelegationMode.
 This change was not specified either for the IDL or for the description
 of the set_credentials operation. Also DelegationMode should be removed from SecurityLevel2.
 
 

Summary: Should Vault::accept_security_context() take a CredentialsList parameter
 or a Credentials (not a list)  like every other operations in Vault?
 
 

Summary: As we realized during the RTF 1.5, we have erroneous text for
 operations that describe passing nil/NULL for parameters.  I"ve
 tracked down a few more:
 
 p. 15-96 [495]: For the requested_privileges parameter, the phrase "(A 
    null attribute set requests default attributes.)" should read "A
    zero length attribute list requests the default attributes." 
 
 p. 15-130 [666]: For the data_included_in_token parameter, the phrase
    "(may be null)" should read "(may be a zero length sequence)".
 
 p. 15-156 [784]: The object_type (which is a repository id) parameter
    is allowed to be nil.  It should read "If this is the empty string, 
    all types are implied."
 
 p. 15-157 [787]: Same as above.
 
 p. 15-171 [846]: For the mechanism parameter, the phrase "Normally
    NULL" should read "Normally the empty string".
 
 p. 15-171 [846]: For the chain_bindings parameter, the phrase
    "Normally NULL (zero length)" should read "Normally a zero length
    octet sequence".
 

Summary: Severity: Yes :)
 Security 1.5:
 Issue: Interoperability. SECIOP needs an internet address designation.
 
 The current specification says that SECIOP goes under GIOP and over IIOP.
 This is misguided, as IIOP is really just a term for GIOP over TCP/IP.
 
 SECIOP doesn"t really have to be over TCP/IP, but it might be helpful
 to think of it that way. However, like SSL, we need away to separate
 SECIOP over TCP/IP and GIOP over TCP/IP. If SECIOP cannot have it"s own
 profile, since now ONE profile can represent multiple protocols, then we
 need a way specify a different internet address (different port), but also
 maybe a different interface card (multihomed hosts).
 

Summary: Currently there is now way to examine the credentials of a server.
 We would like this capability in order to examine the fact that
 we have authenticated who we expected to contact.
 

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.
 

Summary: In ptc/98-12-03 on page 355 paragraph 1689 (second bullet), the 
   examples given for Integrity Violations include trapdoors and 
   viruses; however, just below that in paragraph 1691, "Inclusion 
   of rogue code in the system, which gives access to sensitive 
   information" is explicitly identified as being outside of the 
   scope of the specification.  Since both trapdoors and viruses 
   are examples of rogue code, these two paragraphs contradict 
   each other.
 

Summary: How is a SecAttribute"s value field encoded? How is the
 defining_authority field encoded and what does it represent?
 
 The specification is unclear about this in the data module chapter,
 Appendix A. However, it is clear from the interoperability specification
 that the defining_authority if it exists, it is an OID.