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

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: The model currently specifies that _set_policy_overrides(), and
get_policy() apply to the particular object reference.

That would mean that the policies applied to accessing Current.
I suggest that we aliviate this discrepancy by putting a
CORBA::PolicyManager get_policy_manager() on the Current interface.
The PolicyManager is currently part of the new Async Messaging Specification
and would be a good interface to do this with.

Summary: Using SecurityOpaque causes needless buffer copying. I suggest
a buffer interface.
Using a sequence<octet> for tokens going in and out of
SecurityReplaceable::Vault and SecurityContext imply
(at least in the Java) maps it to an array of fixed length.

This causes the implementations to constantly recopy entire
arrays just to get the length attribute set correctly.

Summary: Okay, I"ll give you there is a need for security features
provided they are only looked at for supported features of
credentials and contexts. Not for setting.
These should be done via setting assoication options and setting the
delegation mode;

To simplfy the semantics of SecurityFeatures and using them,
the spec should specify a good programing model. Otherwise,
examining them and manipulating them becomes ineffcient.

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

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:

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

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: Inconsistent Spelling between Security and SecurityLevel2

Summary: Operations regarding Security Features are too vague, unclear,
can be inconsistent, and most likely, not fully implementable.

Summary: Duplicate DelegationMode(s) in Security and SecurityLevel2

Summary: const EventType AuditObectjCreation = 7;

should be

const EventType AuditObjectCreation = 7;

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?

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