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 357: The generate_token and verify_evidence methods have problems
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 371:
Issue 372: DomainAccessPolicy incorrectly inherits from CORBA
Issue 373: Why do DomainAccessPolicy set methods have family arguments?
Issue 374: How does get_effective_rights get the delegation state?
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 998: AccessPolicy can"t distinguish intiator and delegates
Issue 1404: Typo in 98-01-02
Issue 1633: Paragraph 19, section 15.8.4.2
Issue 1661: Extension to SecurityContext to support SECIOP::DiscardContext
Issue 1723: SecIOP Architecture
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 1765: Credentails.set_privileges()
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 1847: Principal Authenticator
Issue 1930: DelegationMode
Issue 2027: PrincipalAuthenticator and Current
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 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 2201: Interfaces are specified using wrong datatype in CORBASEC
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 2558: ReceivedCredentials.
Issue 2703: How is a SecAttribute"s value field encoded
Issue 2704: Capule Specific items residing on thread specific Current
Issue 2707:
Issue 2708: Which codeset is used in CDR encoding (interop)
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 2789: Security: SSL reference no longer valid
Issue 2800: Public Attribute extraneous and inefficient
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 3262: Regarding Principal Authenticator in security/99-12-02
Issue 3272: SECIOP Sequencing Layer is superfluous and redundant
Issue 3406: Firewall issue regarding SOCKS
Issue 3407: Adding firewall info to the IOR
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 5526: SECIOP ContextId
Issue 5527: SECIOP State Machine Discard

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