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.

Close issue with revised text.

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)

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

;

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

;

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.

Close issue with revised text.

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.

Make it singular. Close issue with revised text.

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.

No Data Available

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.

Apply revised text and close issue

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

;

module GSSUP

;

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.

Close issue with revised text.

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.

Same as issue 4141

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

;

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

Close issue with revised text

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

Make the replacements as suggested above.

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;

editorial, close issue

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.

Close issue as duplicate of 3922

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;

No action needed from the FTF, purely administrative

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.

Close issue with revised text.

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

;

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.

Close issue with revised text.

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

Close issue with revised text.

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

Recommend closure with revised text

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.

Close issue with revised text.

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.

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

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

Close issue with revised text.

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.

Close issue with revised text

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

Apply revised text and close issue.

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.

Close issue with revised text.

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

close issue with no change