Issue 2452:  Inappropriate examples of Integrity Violations (sec-rev)
Source:  (, )
Nature: 
Severity:  Minor
Summary: Summary: In ptc/98-12-03 on page 355 paragraph 1689 (second bullet), the 
   examples given for Integrity Violations include trapdoors and 
   viruses; however, just below that in paragraph 1691, "Inclusion 
   of rogue code in the system, which gives access to sensitive 
   information" is explicitly identified as being outside of the 
   scope of the specification.  Since both trapdoors and viruses 
   are examples of rogue code, these two paragraphs contradict 
   each other.
 

Resolution: Close issue 2452 "Need OID’s exposed in Vault."
Revised Text: Page 15-173:
Add section after paragraph 853 that starts with "The list of
authentication methods supported by this Vault ...".
supported_mech_oids
This readonly attribute contains a sequence of
OIDs each of which identifies a particular GSS
mechanism that the Vault supports.
Appdendix A.3, Page 15-324:
Add the attribute definition to the Vault interface after
"get_supported_mechs":
readonly attribute Security::OIDList supported_mech_oids;
Actions taken:
February 12, 1999: received issue
June 18, 1999: closed issue
Discussion: 

End of Annotations:=====
X-Authentication-Warning: marcy.adiron.com: polar owned process doing
-bs
Date: Fri, 12 Feb 1999 08:18:31 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: issues@omg.org
cc: sec-rev@omg.org, secsig@omg.org
Subject: Issue: mechanism OID's


Document:: Security Chapter 15
Severity:: Critical
Summary:: Need OID's exposed in Vault.
Description:

The Vault specifies what its supported Mechanism and association
options
are.

The document specifies that the tokens created by
init_security_context,
and given to accept_security_context are GSS Tokens of the
InitialToken
type. The Mechanism OID is at the front of the InitialToken
header. This
is used to farm off the initial token to the correct GSS mechanism
processor, such as kerberos, version 4,5,5.2, etc or sesame.

For actual replaceablity we need to map the mechanism to the proper
OIDs.
This is so that the SecIOP processing machinery may be able hand the
initial token off to the correct vault (in the case where there may be
multiple vaults), or send an error message if the OID is not
supported.

Discussion:
Recommendation:

We can add a definition to Security and an attribute to the Vault.

module Security {
	typedef sequence<octet> OID;
	typedef sequence<OID>   OIDList;
};

module SecurityReplacable {
	interface Vault {
		readonly attribute Security::OIDList supported_oids;
	};
};

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
President                     2-212 Center for Science & Technology
mailto:polar@adiron.com       CASE Center/Syracuse University 
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com


X-Authentication-Warning: marcy.adiron.com: polar owned process doing
-bs
Date: Wed, 10 Mar 1999 10:45:18 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Andre Srinivasan <asrinivasan@inprise.com>
cc: sec-rev@omg.org
Subject: Re: Open Issues

On 9 Mar 1999, Andre Srinivasan wrote:

> Issue 2452: We need discussion.

This is about supplying the mechanism OIDs in the vault for the
particular security mechanisms supported by the Vault. Since Security
Replaceable uses GSS tokens, and the mechanism for those tokens are
identified by prepended OID. The internal machinery needs to know that
the
vault can accept a GSS Initial Token for the mechanism. The best way,
it
to ask the object what OIDs it supports.
  
I cannot see why this might be a problem, and the other guy who was
working on Security Replaceable pieces agreed (Nick Brachet).

-Polar