Common Secure Interoperability Avatar
  1. OMG Specification

Common Secure Interoperability — Closed Issues

  • Acronym: CSIv2
  • Issues Count: 23
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
CSIV2-10 ISL changes to break dependency on Security and SECIOP modules CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-9 Multiple Privilege Authorities and Supported Naming Types CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-6 inconsistent definition of target_name field CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-5 Format of GSSUP GSS exported name object undefined CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-1 CSIv2 Protocol CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-12 OIDs CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-11 Module suggestions CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-2 GSSUP Names are inconsistent other security mechanisms. CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-8 INVALID recommended cipher suites CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-7 CSIv2 IOR Tagged component Identifier values CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-4 GSSUP names are incompatible with the Identity Token CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-3 Service ID missing CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-21 CSIv2 TSS state machine lacks states to enforce target policy for CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-20 The encoding of GSSUP ICT's is not clearly specified CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-16 New minor codes for NO_PERMISSION Exception in CSIv2 CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-15 How to Partition the ServiceConfiguration syntax space to support vendor sp CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-19 CSIv2 Issue: SECIOP does not have multiple addresses. CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-18 Inability to specify per method target security requirements CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-23 How to Partition the AuthorizationElementType regarding vendor extensions CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-22 clarification of csiv2 stateful conformance requirements CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-14 Issue: inconsistent definition of AuthorizationToken CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-13 Module SSLIOP Does Not Contain Host CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-17 No Tokens in EstablishContext Message CSIv2 1.0b1 CSIv2 1.0 Resolved closed

Issues Descriptions

ISL changes to break dependency on Security and SECIOP modules

  • Key: CSIV2-10
  • Legacy Issue Number: 4141
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    Section "IDL" Contains dependencies on the IDL of the security
    specification (the SECURITY, SECIOP, and SSLIOP modules)

    Description:

    The IDL for CSIv2 is dependent on the AssociationOptions type of the
    SECURITY module, and proposes some new types to be added to that module.

    The IDL for CSIv2 also proposes some new types to be added to the the
    SECIOP module.

    The IDL for CSIv2 is dependent on the SSL module.

    Proposed Solution:

    1. Move the AssociationOptions type out of the Security Mododule into a
    new base security module. (Issue for the security spec) - Make the
    Security Module dependent on this base security module.

    2. Add new constants to AssociationOptions.

    3. Add to this new base module the new types created for CSIv2 and
    previosly intended to be added to the security module (with the
    exception of the types related to type ScopedName, which will be the
    subject of another issue).

    4. Move the new SECIOP ComponentId and tag structure for TAG_SECIOP
    SEC_TRANS into the CSIIOP module, thus eleiminating the CSIv2 dependence
    on the SECIOP module.

    5. move the SSLIOP module into the CSIv2 spec. Change the SSLIOP modules
    dependency on the security module to a dependency on the new base
    security module.

    6. Change All references to the SECUIRTY module in modules GSSUP,
    SSLIOP. CSI, and CSIIOP to references to the base security module.

    7. Modify the GSSUP, CSI, and CSIIOP modules for idempotent inclusion.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple Privilege Authorities and Supported Naming Types

  • Key: CSIV2-9
  • Legacy Issue Number: 4118
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Multiple privilege authorities and multiple naming types yield
    combinatorial problems for the client.

    Discussion:

    This issue is sort of in the same regards to Issue 3973 where Ron thinks
    that having multiple target_name(s) in the AS_ContextSec is a bad idea, of
    which I agree.

    The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec
    structure sequence<ServiceConfiguration>. It suffers the same problem,
    especially when combined with multiple supported naming types.

    It is completely hard to determine having multiple privilege authorities
    and the names that must be used to assert the identity for the privileges.
    In fact, the client may get back an AuthorizationToken that he doesn't
    understand, but will need to assert an identity for it's use, quite
    possibly with endorsement. Having multiple naming types supported per
    privilege authority is fine, but combine that with multiple ones, and you
    may get a decision problem for the client.

    It is better to be able to specify a one-to-one correspondence, locking
    down the combinations that a server will accept, and the client doesn't
    have to do any mucking about deciding what will work.

    Proposed Solution:

    Singularize the privilege authorities field.

    Unfortunately IDL has a hard time making a singular field become optional
    without doing something bizzare, such as:
    switch(boolean)

    { true: ServiceConfiguration privilege_authority }

    which requires a new type, etc.

    I have two proposals:

    Proposal 1:

    We signularize the field in name, i.e. "privilege_authority". Keep the
    sequence definition. However, stating in the specification at most one
    must be contained. This can be hinted at as well in IDL.

    struct SAS_ContextSec

    { Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; sequence <ServiceConfiguration,1> privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }

    ;

    Proposal 2:

    We specify a ServiceConfigurationSyntax tag for "none", and specify that
    the sequence of octet associated with it is empty.

    // Corresponding ServiceName for the SCS_None Syntax should be an empty
    // sequence octets.
    const ServiceConfigurationSyntax SCS_None = -1;

    struct SAS_ContextSec

    { Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceConfiguration privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }

    ;

    For efficiency I'm in favor of the second approach, because I can just
    look a the ServiceConfiguration::syntax field and know what to do. The
    first proposal causes me to look at the length first, index to the first
    element in the array, and then look at the syntax field.

    As an aside, I also wouldn't mind changing the sequence<Security::OID>
    type into a Security::OIDList, but that can be the subject of another
    issue. Also note, to be specific with the document I am pointing to, I
    used the "Security" definitions. Hopefully, we will follow one proposal to
    change the Security::AssociationOptions to CSIIOP::AssociationOptions and
    Security::OID and Security::OIDList to CSI::OID and CSI::OIDList
    respectively.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistent definition of target_name field

  • Key: CSIV2-6
  • Legacy Issue Number: 3973
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    target_name(s) field of struct AS_ContextSec is defined and described
    inconsistently in various places in the submission.

    Description:

    In section 6.1.4.1 this field is defined as

    sequence <Security::GSS_NT_exportedName> target_names;

    and defined as a list of target names.

    In the IDL in section B.7 this field is defined as

    sequence <Security::GSS_NT_exportedName> target_name;

    There are other places in the document where the singular form of this
    field name is used, including in the examples of the scenarios chapter.

    Proposed Solution:

    The change of this field to a list was not necessary, as it is difficult
    to make a case for requiring multiple target names within a single
    mechanism (as there is a multiple mechanism workaround).

    We should at least fix the inconsitencies in the document. If we keep
    the
    ability to express multiple targets, then we should also say something
    about the semantics of position in the list.

    The prefered solution would be to revert back to the singular form.

    Security::GSS_NT_exportedName target_name;

    and fix all references to this field accordingly.

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Make it singular. Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Format of GSSUP GSS exported name object undefined

  • Key: CSIV2-5
  • Legacy Issue Number: 3972
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    Format of GSSUP GSS mechanism-independent exported name object, a
    special form of "flat" name as described below, is not defined.

    Description:

    >From RFC 2473 section 1.1.5 Naming

    > Different classes of name representations are used in conjunction
    > with different GSS-API parameters:
    >
    > - Internal form (denoted in this document by INTERNAL NAME),
    > opaque to callers and defined by individual GSS-API
    > implementations. GSS-API implementations supporting multiple
    > namespace types must maintain internal tags to disambiguate the
    > interpretation of particular names. A Mechanism Name (MN) is a
    > special case of INTERNAL NAME, guaranteed to contain elements
    > corresponding to one and only one mechanism; calls which are
    > guaranteed to emit MNs or which require MNs as input are so
    > identified within this specification.
    >
    > - Contiguous string ("flat") form (denoted in this document by
    > OCTET STRING); accompanied by OID tags identifying the namespace
    > to which they correspond. Depending on tag value, flat names may
    > or may not be printable strings for direct acceptance from and
    > presentation to users. Tagging of flat names allows GSS-API
    > callers and underlying GSS-API mechanisms to disambiguate name
    > types and to determine whether an associated name's type is one
    > which they are capable of processing, avoiding aliasing problems
    > which could result from misinterpreting a name of one type as a
    > name of another type.
    >
    > - The GSS-API Exported Name Object, a special case of flat name
    > designated by a reserved OID value, carries a canonicalized form
    > of a name suitable for binary comparisons.

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CSIv2 Protocol

  • Key: CSIV2-1
  • Legacy Issue Number: 3906
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    ssue on Document orbos/2000-08-04, CSIv2 Joint Submission:

    Document: orbos/2000-08-04 CSIv2 Joint Submmission
    Subject: Protocol and IOR incompatabilities for Identity Assertion
    Severity: Critical

    Summary:

    The CSIv2 protocol is too vague on acceptance of identity tokens.
    This yeilds an uneeded and unwarranted complexity in implemenations.
    Vague protocols are not a good idea. It limits interoperability.

    Discussion:

    In the IOR, the CSIv2 protocol states a list of OIDs signifying the
    acceptable forms of an IdentityToken delivered by the client. This list of
    acceptable name forms is stated only to apply to GSS_NT_ExportedName
    types. There are no OIDs signifying that an X.501 DN or X.509 Public Key
    Certificate are acceptable.

    It seems that the specification is written so that both X.501 DNs and
    X.509 Certificate chains are always acceptable. This requirement would
    cause all clients to send only X.501 DNs or X.509 Certificate Chains,
    regardless of the server listing its acceptable name types. Also, there is
    no indication of which of an X.501 DN or X.509 Public Key Certificate
    Chain is desirable. This is vague.

    It is completely unwarranted to tell all CSI mechanisms that they must
    support X.509 DNs or X.509 Certificate chains. These name forms may not be
    relevant to the mechanism at all. The mechanism may not support public key
    technology, have facility for verification of certificates, may not be
    able to parse X.501 DNs or X.509 Certificate Chains, and further more, but
    not least, the security mechanism may not know what to do with it. One
    example, might be an TCPIP CSI mechanism that only wants to accept
    Kerberos principal names, Unix user names, or NT user names. DNs or
    Certificate Chains are irrelevant.

    With that in mind, a client should not be allowed to send the server an
    X.509 certificate chain or an X.501 DN at it. Those name forms are not
    acceptable to the server.

    The easiest way around this problem is to allocated OIDs under the OMG OID
    that signify the acceptance of each of the X.509 DNs and X.509 Public Key
    Certificate chains. Servers that accept X.501 DNs and X.509 Public Key
    Certificate chains for identity assertion shall list the appropriate OIDs
    in the IOR.

  • Reported: CSIv2 1.0b1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Apply revised text and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OIDs

  • Key: CSIV2-12
  • Legacy Issue Number: 4143
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    There is a need to define OIDs, at least one for GSSUP. However, an OID is
    represented by a sequence of positive integers, encoded as a octet
    sequence. The encoding has the property that two encodings are equivalent
    if and only if their definitions are equivalent (which is something ASN.1
    DER is not particulary good at).

    We cannot define a costant in IDL for a sequence of octets. However, I've
    seen an number of ASN.1 compilers and it seems that the internal form of
    the definition of an OID is a string of natural numbers in base 10
    separated by dots. This is a parseable representation, and widely used.

    I suggest that we introduce a definition, possibly a type, for and OID
    string representation.

    module CSI

    { // // An OID String Representation. // The OID is represented in dot format. // For example, "2.23.130.1.1.1". // typedef string OIDStringRep; }

    ;

    module GSSUP

    { const OIDStringRep GSSUP_OID_DEF = "2.23.130.1.1.1"; }

    ;

    This will allow ASN.1 compilers to at least map from this internal string
    representation if they don't already do so.

    What do you think? If there is consensus, I'll raise an issue, and we can
    resolve it.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Module suggestions

  • Key: CSIV2-11
  • Legacy Issue Number: 4142
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    In looking at it, I think CSI would make a good "base" module.

    Since other modules are only related to CSI, such as CSIIOP and GSSUP, I
    see no reason why those two modules cannot depend on CSI.

    Define in CSI:

    AssociationOptions
    GSSToken
    GSS_NT_ExportedName
    X509CertificateChain
    X501DistinguishedName

    As part of another issue, change the use of ScopedName in GSSUP to
    CSI::GSS_NT_ExportedName.

    As yet another issue, is to get rid of the ASN.1 dependance on
    X509CertificateChain and X501DistinguishedName and somehow make it
    consistent with the PKI spec. Or get rid of them all together, and just
    use ExportedName format with proper OIDs.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Same as issue 4141

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GSSUP Names are inconsistent other security mechanisms.

  • Key: CSIV2-2
  • Legacy Issue Number: 3922
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Joint Submission
    Subject: GSSUP Names are inconsistent other security mechanisms.
    Severity: Medium

    Summary:
    The names supplied in the InitialContextToken for the UserName password
    scheme invents a name type called a Security::ScopedName. This is just yet
    another name type that must be dealt with and is completely inconsistent
    with anything else used for names. The contents of the scope and the name
    are underspecified.

    Discussion:
    The structure should allow for all forms of name types. The easiest
    way to do accomplish consistency is to use a GSS exported Name type.

    struct InitialContextToken

    { Security::GSS_NT_ExportedName username; Security::UTF8String password; }

    ;

    That way a password database can even store names that are DN's,
    X509GeneneralNames, Kerberos Names, NT Usernames, etc.

  • Reported: CSIv2 1.0b1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

INVALID recommended cipher suites

  • Key: CSIV2-8
  • Legacy Issue Number: 3975
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    Section "5.2.1" Recommended SSSL/TLS Ciphersuites" incorrectly names 4
    cipher suites.

    Description:

    The first 4 cipher suites in the recommended list do not exist as they
    were named. The invalid appearing in this list are:

    TLS_RSA_EXPORT_WITH_RC4_128_MD5
    SSL_RSA_EXPORT_WITH_RC4_128_MD5
    TLS_DHE_DSS_EXPORT_WITH_DES_CBC_SHA
    SSL_DHE_DSS_EXPORT_WITH_DES_CBC_SHA

    Proposed Solution:

    Replace the invalid names listed above with the following:

    TLS_RSA_WITH_RC4_128_MD5
    SSL_RSA_WITH_RC4_128_MD5
    TLS_DHE_DSS_WITH_DES_CBC_SHA
    SSL_DHE_DSS_WITH_DES_CBC_SHA

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Make the replacements as suggested above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CSIv2 IOR Tagged component Identifier values

  • Key: CSIV2-7
  • Legacy Issue Number: 3974
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:
    tagged component identifier values must be assigned for
    components TAG_NULL_TAG, TAG_CSI_SEC_MECH_LIST, and
    TAG_SECIOP_SEC_TRANS.

    Description:

    const IOP::ComponentId TAG_CSI_SEC_MECH_LIST = aa;
    const IOP::ComponentId TAG_NULL_TAG = bb;
    const IOP::ComponentId TAG_SECIOP_SEC_TRANS = cc;

    Numerical values must be reserved within the OMG tag list to
    identify these new tagged components. These values will replace the
    temporary values, "aa", "bb", and "cc" appearing in the submission.

    Discussion:

    Proposed Solution:

    const IOP::ComponentId TAG_CSI_SEC_MECH_LIST = 33;
    const IOP::ComponentId TAG_NULL_TAG = 34;
    const IOP::ComponentId TAG_SECIOP_SEC_TRANS = 35;

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    editorial, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GSSUP names are incompatible with the Identity Token

  • Key: CSIV2-4
  • Legacy Issue Number: 3948
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    The name type used in the GSSUP mechanism for Client Authentication over
    the transport name type is not convertible to anything used by the
    Identity Token. This situation becomes a problem when on the server side
    where you need to quote, (i.e. identity assert) the client's authenticated
    identity to another CSIv2 CORBA outcall on behalf of the client.

  • Reported: CSIv2 1.0b1 — Fri, 13 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue as duplicate of 3922

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service ID missing

  • Key: CSIV2-3
  • Legacy Issue Number: 3932
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    CSIV2 service context element, SecurityAttributeService,
    must be assigned a service id.

    Description:

    const ServiceId SecurityAttributeService = xx;

    A numerical value must be reserved within the OMG service
    id space to identify CSIv2 service context elements. The
    value will replace the temporary value ("xx") appearing in the
    submission.

    Discussion:

    Proposed Solution:

    const ServiceId SecurityAttributeService = 15;

  • Reported: CSIv2 1.0b1 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    No action needed from the FTF, purely administrative

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CSIv2 TSS state machine lacks states to enforce target policy for

  • Key: CSIV2-21
  • Legacy Issue Number: 4326
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    While in state "Waiting for Request", The TSS state machine will accept
    an unprotected request, without consideration of the target CSIv2
    security policy.

    Also the specification does not describe what is supposed to happen when
    a target's mechanism definitions/policy requires SAS (i.e. client
    authentication) and the CSS does not send an EC.

  • Reported: CSIv2 1.0b1 — Wed, 30 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The encoding of GSSUP ICT's is not clearly specified

  • Key: CSIV2-20
  • Legacy Issue Number: 4308
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf

    Isuse: The encoding of GSSUP ICT's is not clearly specified

    Para 48 states:

    [48] The format of a GSSUP initial context token shall be as defined in
    [IETF RFC 2743]
    Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This
    GSSToken shall
    contain an ASN.1 tag followed by a token length, an authentication
    mechanism
    identifier, and a CDR encoded sequence of octets corresponding to a
    GSSUP inner
    context token as defined by the type GSSUP::InitialContextToken in
    Section 16.9.2,
    “Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59
    (and
    repeated below).

    and section
    16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats
    states

    // The following structure defines the inner contents of the username
    // password initial context token. This structure is CDR encoded in a
    // sequence of octets and appended at the end of the username/password
    // GSS (initial context) Token.

    struct InitialContextToken

    { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }

    ;

    Proposed Resolution:

    Change para 148 to the following:

    [48] The format of a GSSUP initial context token shall be as defined in
    [IETF RFC 2743]
    Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This
    GSSToken shall
    contain an ASN.1 tag followed by a token length, an authentication
    mechanism
    identifier, and an encapsulation octet stream containing a CDR encoded
    GSSUP inner
    context token as defined by the type GSSUP::InitialContextToken in
    Section 16.9.2,
    “Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59
    (and
    repeated below).

    change the relevant comment in
    16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats
    to the following

    // The following structure defines the inner contents of the username
    // password initial context token. This structure is CDR encoded in an
    // encapsulation octet stream and appended at the end of the
    username/password
    // GSS (initial context) Token.

  • Reported: CSIv2 1.0b1 — Tue, 15 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New minor codes for NO_PERMISSION Exception in CSIv2

  • Key: CSIV2-16
  • Legacy Issue Number: 4277
  • Status: closed  
  • Source: International Business Machines ( Dr. Daniel T. Chang)
  • Summary:

    Don,
    >
    > Although the minor codes of the NO_PERMISSION exception have been defined
    > in Table 4-7, Section 4.5, of the 7/21/2000 version of the CSIv2
    > Specification, in order
    > for the server to properly communicate the caused of the NO_PERMISSION
    > exception
    > to the client, we would like to propose the additional minor codes to the
    > NO_PERMISSION
    > exception.
    >
    > ***********************************************************************
    > NO_PERMISSION authentication error minor codes: range 1-100
    > (Note: The following minor codes are defined in the current CSIv2 spec:
    >
    > 1 - Invalid evidence
    > 2 - Invalid mechanism
    > 3 - Conflicting evidence
    > 4- No Context
    > )
    > The new proposed minor codes for NO_PERMISSION exception: The numbering
    > scheme was chosen to group errors into areas of
    > similarity.
    >
    > 5 - user id not defined to security system - the user may select another
    > userid
    > 6 - user id revoked by security system - the user may select
    > another userid
    >
    > 11 - password invalid for this userid - the user may correct the password
    > 12 - password expired - the user may select another userid
    >
    > 20 - credentials expired - the user may select different credentials or
    > renew them(e.g. by reissuing kinit)
    > 22 - credentials invalid - the user may select different
    > credentials, (e.g.
    > by kinit, or specifying a different PKCS certificate handle)
    >
    > 52 - new password doesn't meet installation requirements
    >
    > 60 - general authentication error - the user should resubmit his
    > credentials, but not additional information as to what is in error is
    > provided.
    > ******

  • Reported: CSIv2 1.0b1 — Wed, 18 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to Partition the ServiceConfiguration syntax space to support vendor sp

  • Key: CSIV2-15
  • Legacy Issue Number: 4268
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    We need to define how the namespace of ServiceConfiguration syntax
    identifiers (used in privilege_authorities) is to be partitioned
    so that individual vendors have some identifiers reserved for
    their use (i.e. the definition of vendor specific syntaxes).

  • Reported: CSIv2 1.0b1 — Wed, 11 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Recommend closure with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CSIv2 Issue: SECIOP does not have multiple addresses.

  • Key: CSIV2-19
  • Legacy Issue Number: 4293
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    This issue is the exactly the same issue as issue 4200, which
    is for TLS (SSL) transport addresses. It notes that the
    component for a SECIOP transport needs to support multiple
    addresses.

    The recommended solutioin to this issue is to adopt the analogous
    resolution to the 4200 issue.

  • Reported: CSIv2 1.0b1 — Thu, 3 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inability to specify per method target security requirements

  • Key: CSIV2-18
  • Legacy Issue Number: 4282
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    The CSIv2 mechanism definition schema, soes not provide a way to
    associate mechanisms with subsets of the methods of an object.

    Discussion

    EJB method-permissions may be associated with subsets of methods, such
    that a class of EJB objects may have some protected and some unprotected
    methods. Where by protection I mean, the caller must be authenticated
    and be in a authorized role, to access the method. Some methods of an
    EJB may be available to unauthenticated callers, while others may limit
    access to only specific authenticated callers.

    Given a mixed protection object, how would one define its IOR such that
    it could be affectively accessed by its clients without

    1. eliminating unauthenticated access to the object

    that is, mark the target as authentication required

    2. causing unnecessary authentications and usurping the
    clients perogative to only authenticate when it is required to or
    chooses to.

    that is, mark the target as authentication supported and tell the
    client to authenticate if it can

    3. causing failed attempts because the client does not know that
    the target requires authentication

    that is, mark the target as authentication supported and let the
    client authenticate if it wants to

    Would it be appropriate to add information to the IOR, that indicates
    that whether the object will check permissions, such that a client
    normally operating in mode 3, would know when it would probably do
    better in mode 2?

    Should a CSIv2 IOR which principally defines (authentication and msg
    protection mechanisms) carry additional information about the
    authorization policy of the object? There is obviously some precedent
    for doing so in the privilege authorities field.

  • Reported: CSIv2 1.0b1 — Tue, 24 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with no change as this does not apply to CSIv2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to Partition the AuthorizationElementType regarding vendor extensions

  • Key: CSIV2-23
  • Legacy Issue Number: 4330
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    We should define how the namespace of AuthorizationElementType
    identifiers (used in authorization tokens) is to be partitioned
    so that individual vendors have some identifiers reserved for
    their use (i.e. the definition of vendor specific type identifiers).

  • Reported: CSIv2 1.0b1 — Fri, 1 Jun 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clarification of csiv2 stateful conformance requirements

  • Key: CSIV2-22
  • Legacy Issue Number: 4327
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    The specification is currently weak on its description of what must
    be done by a TSS with respect to designating a "stateful" value in its
    IOR's, and in defining under what circumstances a TSS may claim stateful
    conformance. In particular, the spec does not currently state whether or
    not a TSS must be stateful for all of its mechanism definitions, at all
    of its target objects in order to claim stateful conformance. The
    following paragraphs should be included to clarify these two issues.

  • Reported: CSIv2 1.0b1 — Wed, 30 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: inconsistent definition of AuthorizationToken

  • Key: CSIV2-14
  • Legacy Issue Number: 4221
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: csiv2-011701

    In section 16.2.3

    The AuthorizationToken type is defined inconsitently with respect to its
    definition in IDL module CSI.

    typedef sequence <X509AuthorizationElement> AuthorizationToken;

    in module CSI

    typedef sequence <AuthorizationElement> AuthorizationToken;

    The definition in 16.2.3 should be chnaged to agree with that in the IDL

  • Reported: CSIv2 1.0b1 — Tue, 13 Mar 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Apply revised text and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Module SSLIOP Does Not Contain Host

  • Key: CSIV2-13
  • Legacy Issue Number: 4200
  • Status: closed  
  • Source: Mansurus LLC ( Donald Flinn)
  • Summary:

    In some situations, e.g. a multi-homed system, there would have to be a profile for each port number supported by SSL. This is inefficient. Adding a String host_name to the struct SSL in the Module SSLIOP would resolve this issue.

  • Reported: CSIv2 1.0b1 — Mon, 12 Feb 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Tokens in EstablishContext Message

  • Key: CSIV2-17
  • Legacy Issue Number: 4281
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    The spec doesn't say whether or not an EstablishContext with none
    of cleint authentication, identity, or authorization token is
    legitimate.

    I don't think we need the ability to send such mecahnisms (for
    unprotected requests), as we would just send the request without a CSIv2
    service context element. The only down side I can see, to writing this
    empt EstbalishContext out of spec, would be that a client could not use
    it to get feedback from a TSS in the form of CompleteEstablishContext,
    indicating that the TSS supports CSIv2.

    We must indicate that this is either an invalid msg, or state that it
    must be supported (and what it's semantics should be).

  • Reported: CSIv2 1.0b1 — Tue, 24 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    close issue with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT