CORBA Security SECIOP.

In SECIOP, one RTF changed a field in the SECIOP Message Header
from

struct ulonglong

;

// This should be changed to unsigned long long
typedef ulonglong ContextId;

to

typedef unsigned long long ContextId;

because of the introduction of the long long type into CORBA.

This modification changes the specification the CDR encoding of the
structure, because what was compact 8 byte sequence aligned on a 4 byte
boundary. now became an 8 byte sequence aligned on an 8 byte boundary.

Each SECIOP message is preceded with a GIOP Message header, which is 12
bytes. Each SECIOP message, which is specified by a struct, starts with
the ContextId. Strict interpretation of the encoding rules makes the
SECIOP messages incompatiable, as the space between the header and the
message must now contain 4 bytes padding.

Proposed Resolution: revert back to the struct ulonglong definition.

2. The other problem I could see was related to adding firewall info to the
IOR. If a client makes a call to a server thru a firewall(s) and the server
returns (1.0) IOR's then those IOR's should have the firewall information
added to them. The other problem is that if the client calls the server and
passes an IOR with firewall info in it then there are other issues, for
example

• The IOR passed has the same firewall info as the IOR of the
  objects being called. In this case the server should strip off the firewall
  information in order to use the IOR.
• The IOR passed has different firewall info than the IOR of the
  objects being called. In this case the server should keep the firewall info.

This implies that the marshalling and unmarshalling code should add/remove
firewall info to IOR depending on the firewall information of the objects
IOR.

Subject: There is no way to find out how Tagged Components are
generated for replaceable security mechanisms. This
should be a function of the Vault, as it is the
center piece of security mechanism replaceablablity.

The Security Replaceablity interfaces are deficient in the aspect of
creating the correct components for the IIOP profile of the IOR for the
specified credentials.

The Vault::init_security_context, takes a parameter, mech_data, which is
the data component of the tagged component that was selected by the ORB
from the IOR for which the mechanism that was used in starting the secure
association.

However, analogously on the accepting side, there is no way to create a
tagged component for use in the IOR! Adding functionality to the vault
will complete the security replaceablity and fill this hole.

I suggest to add the following definitions to Security Replaceable.

#include <IOP.idl>

typedef sequence<IOP:TaggedComponent> TaggedComponentList;

interface Vault

;

The Vault produces the correct IOP tagged components for the set of
credentials specified that will be placed in the IIOP profile.

There is no definite 1 to 1 correlation between the credentials in the
given list and the tagged components generated. The vault may determine
that some credentials are redundant, irrelevant, or take precedence over
other credentials.

I wanted to raise some issues with the firewall report (Firewall RTF)
related to SOCKS and IOR's.

1. If information is required for authentication with the socks server then
there is no direction given on how to get this. The solution should not be
pop up a dialog because server programs would hang. It would be nice to have
some kind of callback to the orb clients that could request password. Then
the client could decide to throw an error or pop up a dialog box.

There is a requirement to pass a sequence of IOP::TaggedComponents between
interfaces of different modules, namely SecurityReplaceable and Portable
Interceptors.

We would like to see a typedef in module IOP of:

module IOP

;

Due to different language mappings and the way they handle typdefs, a
definition in a common place is needed instead of having each module
define their own typedef for a sequence<IOP::TaggedComponent> as this
approach would provide for a difficult hand-off for the type.

The RequiredRights are confusing. (Issue raised within the RTF itself).

The Rights combinators SecAllRights and SecAnyRights are underspecified.
The notes on the implemenations of Required Rights are confusing.

Certain parameters of locality constrained interfaces were using
"sequence octet" due to the inherent fear of CORBA any's. This should not
be a problem. Also it is a serious bug as this might requires unnecessary
marshalling of data to pass into the operations of locality constrained
objects.

The interfaces, their operations and parameters that are affected follow:

PrincipalAuthenticator
authenticate
auth_data,continuation_data,auth_specific_data
continue_authentication
response_data,continuation_data,auth_specific_data
AuditDecision
audit_write
event_specific_data
Vault
acquire_credentials
auth_data,continuation_data,auth_specific_data
continue_acquisition
response_data,continuation_data,auth_specific_data

These parameters should have the type "any".

References 19, Simple GSS Negoiation
Reference 20, Simple Public Key Mechanism

are web pointers, non-existant and need to be updated.
RFC numbers exist for these, specifically RFC2478, and RFC2025
respectively.

Subject: Need MechanismType identifier for TAG_GENERIC_SEC_MECH
components.
Discussion:

Mechanism Type identifier is said to be constructed by the IOR's tagged
component identifier. However, under the current specification, all
mechanisms represented by the TAG_GENERIC_SEC_MECH still need to be
further distinguished by their security_mechanism_type identifier.

The SECIOP State machine has a problem with Discard context. The
specification currently specifies that if either side sends a Discard
Context, the context is discarded on both sides immediately. Therefore, a
client must wait to send a Discard context considering all messages sent
until it can figure out if all expected messages are received.

This situation causes too much coordination between the upper ORB layers
and the lower transport layers in SECIOP. The SECIOP state machine must be
knowledgeable about requests and whether they expect a repose. Then the
SECIOP message layer must know about GIOP message structures.

The proposed way to do this is when a Discard context is sent, it says
that no more data will be sent in that direction. The peer must respond in
kind with a Discard Context message when all data is sent back. Then the
context shall be closed.

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

Summary: I"m having real problems trying to interpret the specification on the
own_credentials list.
I"m working from the Security Spec 1.2, 5 Jan 1998
It seems to be implied by paragraph 4 of 15.5.4.1 Description of
Facilities on page 15-87, which says:

Credential objects are created as a result of:

o Authentication (see Section 15.5.3, "Authentication of Principals", on
page 15-85.
o Copying an existing Credentials Object
o Asking for a Credentials object via Current (see Section 15.5.6,
"Security Operations on Current" on page 15-97).

and, by paragraph 7 of section 15.5.6.3 SecurityLevel2::Current
Interface:

own_credentials

Any application owns a set of credentials which it obtains through the
process of authentication of the principal that initiates the execution of
the program, and further from other credentials that such a principal
might bestow upon the application. This attribute returns this set of
credentials.

Okay, so the problem is that these statements imply, but do not explicitly
stipulate that the PrincipalAuthenticator puts Credentials objects on the
"own_credentials" list.

Summary: SecurityCurrent should probably inherit from PolicyCurrent to marry this
functionality of dealing with policies. However, the messaging
specification I don"t think is "adopted", although it has an RTF. I don"t
know what is the proper procedure about RTFing things on not-yet adopted
technology.
The PolicyManager has a serious, or at least I
think it"s serious flaw. The PolicyManager has "get_policy_overrides" and
"set_policy_overrides" functions. So does CORBA::Object. However, the
problem is. Not only do these operations on PolicyManager have different
semantics than the corresponding ones on CORBA::Object,
"set_policy_overrides" has a different signature!

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

Summary: The CORBASecurity spec. uses three different datatypes for interfaces:

InterfaceDef
RepositoryID
Identifier

InterfaceDef should definitely NOT be used, as it can"t be resolved without
reference to the
Interface Repository, which would be a big performance penalty for cases where
the interface"s
name is simply being matched or used as a lookup key in a local table.

Identifier is also the wrong type; it"s a generic string type and hence not
type-safe with respect
to interface names.

Summary: Policies in SecurityAdmin are unclear in their interpretations. It is
clear from discussions we have had in the group, that too many different
interpretations can ensue.

This is a problem with trying to define security policy in IDL. There
should be a minimum interface that may be supported that will allow a
language description to be taken as an argument, that will define the
policy for the policy object. The query interfaces may be the same.

Summary: I think we have a further problem representing the received
credentials from the server.

We have more than just two attributes on received credentials
which are more suited to the nature of a client, as opposed
to a server/target. We have

readonly attribute Credentials accepting_credentials;
readonly Security::DelegationState delegation_state;
readonly attribute Security::DelegationMode delegation_mode;
readonly attribute Security::AssociationOptions
association_options_used;

What do we do about delegation_state or delegation_mode
for received credentials from the server?