This form contains a series of questions that need to be answered. As you go about answering the questions, please keep the following things in mind:

• While it is not required that each question be answered at this time, all questions must have answers before the response is submitted to The Open Group for review and publication.
• Press the "Save" button at any time to save work in progress. Once the work has been saved, there is the option to continue editing if required.
• Many questions have instructions to assist in development of answers. They are marked with the indicator. Please look at the instructions carefully.
• Although HTML markup can be included in answers, this is not recommended apart from basic tags such as <p> and <br>, since incorrect markup could effect the format of other items in the document.
• Questions on this system should be addressed to the Conformance Statement manager at The Open Group.

Enter the name of the Organization that produced the implementation and the name of the author of the Conformance Statement.

1. Secure Communications Services

Product Information

Environment Specification

Answer the questions for each binary-compatible family. Alternately, provide the answers in the Appendix at the end of this document.

	Testing Environment	Binary-compatible Family	Portability Environment	Indicator of Compliance	Compliance Details
				Select from this list Test report from test suite	None.
				Select from this list Test report from test suite	None.
				Select from this list Test report from test suite	None.
				Select from this list Test report from test suite	None.
				Select from this list Test report from test suite	None.

Temporary Waivers

1.1 Security Mechanisms

Question 1: What security mechanisms are supported?

Response

For each supported mechanism, enter the mechanism's name, object identifier (oid) and a reference to a published mechanism. In the description box, enter a short description of the mechanism and answer the following questions:

• State which features (of delegation, mutual authentication, replay detection, out-of-sequence message detection, message integrity, confidentiality) are supported.
• State whether additional token exchanges may be performed in the course of context establishment (using gss_s_continue_needed).
• Describe all the qualities of protection that the mechanism supports and give the numerical values that identify them in C language binding function arguments.
• State what the default quality of protection is.
• Describe all the name formats that can be used in conjunction with the mechanism, in particular giving the oids associated with them and the character sets and encodings that they use.
• List and describe all the minor status codes associated with the mechanism, giving the numerical values returned by the functions in the C language binding.
• Define all concrete data element formats. in particular, the formats of all tokens that can be exchanged between peer applications must be specified in detail.
• Describe any constraints on channel binding formats, including any constraints on addresses and address types that may appear in them.
• State whether expiration of credentials is supported and, if so, give the default expiration time.



Name: Object Id: Reference: For each of the following categories, state which features are supported. Delegation Mutual Authentication Replay Detection Out of Sequence Message Detection Message Integrity Confidentiality Qualities of Protection Name Numerical Value Description What is the default quality of protection? Name Formats Format Object Id Character Set Encoding Minor Status Codes Code Numerical Value Description Define all concrete data element formats. Describe any contraints... Is expiration of credentials supported? Yes   No If so, what is the default expiration time?

Rationale

A conformant implementation must provide reference to the published specifications that give a complete description of the security mechanism or mechanisms concerned. The referenced material must address the following areas of rationale:

1. In order to establish a security context successfully with a target peer, it is necessary to identify an appropriate underlying mechanism type supported by both initiator and target peers.
2. The underlying mechanism type may allow additional token exchanges to be performed in the course of context establishment.
3. Some mechanism types provide their users with fine granularity control over the means used to provide per-message protection, allowing callers to trade off security processing overhead dynamically against the protection requirements of particular messages.
4. The GSS-API avoids the prescription of naming structures, recognising that different mechanisms process and authenticate names presented in different forms.
5. The GSS-API provides for major and minor status return values. Minor values provide more detailed status information and may include status codes that are specific to the particular mechanism type.
6. Object identifiers must be assigned to candidate GSS-API mechanisms and the name types they support. Concrete data element formats must be defined for candidate mechanisms.
7. Agreements among mechanism implementors define conventional interpretations for the contents of channel binding arguments, including address specifiers (with content dependent on the communication protocol environment) for context initiators and acceptors. Individual mechanisms may impose additional constraints on addresses and address types that may appear in channel bindings.
8. It is possible to request the desired number of seconds for which a context should remain valid, supplying 0 to request a default validity period. But the implementation may not support expiration of credentials.

Reference

See the following sections of the X/Open CAE Specification, Generic Service API (GSS-API) Base:

• Section 2.7.4, Mechanism Types
• Section 3.2, Context-level Calls and Chapter 8, C-language Reference Manual Pages, gss_init_sec_context()
• Section 2.8.4, Quality of Protection and Chapter 8, C-language Reference Manual Pages, relevant functions (e.g., gss_get_mic())
• Section 2.7.5, Naming and Section 7.10, Names
• Section 2.8.1, Status Reporting and Section 7.9.2, Mechanism-specific Status Codes
• Section 5.1, Identification and Section 5.2, Mechanism-independent Token Format
• Section 2.7.6, Channel Bindings and Section 7.11, Channel Bindings
• Chapter 8, C-language Reference Manual Pages, gss_acquire_cred() and gss_init_sec_context(), description of time_rec (in and out)
See also Section 7.4, Object Identifiers.

Question 2: What is the default mechanism?

Response

Rationale

For desired_mechs, the empty set requests a system-selected default.

GSS_C_NULL_OID_SET may be used to obtain an implementation-specific default mechanism.

Reference

X/Open CAE Specification, Generic Service API (GSS-API) Base, Section 2.7.4, Mechanism Types, Section 3.1, Credential-management Calls and Chapter 8, C-language Reference Manual Pages, gss_acquire_cred().

1.2 Support for the Confidentiality and Delegation Services

Question 3: Does the implementation provide Confidentiality Services?

Response

Yes   No

Rationale

GSS-API implementations may optionally include Confidentiality Services, which allow a context initiator to confidentiality-protect its data sent to a context acceptor.

Reference

X/Open Component Definition, Secure Communication Services. See also X/Open CAE Specification, Generic Service API (GSS-API) Base, Section 2.3, GSS-API (Base) - Conformance.

Question 4: Does the implementation include Delegation Services?

Response

Yes   No

Rationale

GSS-API implementations may optionally provide Delegation Services, which allow a context initiator to delegate its credentials to a context acceptor.

Reference

X/Open Component Definition, Secure Communication Services. See also X/Open CAE Specification, Generic Service API (GSS-API) Base, Section 2.3, GSS-API (Base) - Conformance.

Question 5: Does the implementation support multiple name spaces?

Response

Yes   No

Rationale

An implementation may support names drawn from multiple name spaces.

Reference

X/Open CAE Specification, Generic Service API (GSS-API) Base, Section 2.7.5, Naming and Section 7.10, Names.

Question 6: If the answer to Question 5 is yes, and the name spaces are in-built rather than user definable, what are their identification details?

Response

For each supported name space, enter its name, object identifier (oid), character set is uses (e.g. BASIC LATIN), character set encoding (e.g. ASCII) and a brief description.



	Name	Oid	Char Set	Encoding	Description

Rationale

The syntax of a printable name, as defined by the implementation, may be dependent on the local system configuration or on individual user preference. Where multiple name spaces are supported, the internal form of the name must include fields that identify the name space from which the name is drawn. The name from which a printable name is drawn is specified by an accompanying object identifier.

Reference

X/Open CAE Specification, Generic Service API (GSS-API) Base, Section 2.7.5, Naming and Section 7.10, Names.

1.3 Credentials

Question 7: What access-control policy is applied by gss_acquire_cred()?

Response

Rationale

GSS-API implementations shall impose a local access-control policy on callers of this function.

Reference

X/Open CAE Specification, Generic Service API (GSS-API) Base, Section 2.7.1, Credentials and Chapter 8, C-language Reference Manual Page, gss_acquire_cred().

1.4 Security Contexts

Question 8: Does the implementation allow the gss_process_context_token() function to be used for deleting security context?

Response

Yes   No

Rationale

There are two methods of deleting security context, the second of which is optional:

1. The peers within a security context coordinate between themselves and both sides issue their own calls to gss_delete_sec_context().
2. One peer uses gss_delete_sec_context() to delete its side of the security context and to obtain a token to pass to the other peer. The other peer uses the token in conjunction with gss_process_context_token() to delete its side of the security context.

Reference

X/Open CAE Specification, Generic Service API (GSS-API) Base, Chapter 8, C-language Reference Manual Pages, gss_process_context_token() and gss_delete_sec_context().

Question 9: If the answer to Question 8 is yes, in what ways does the effect of using one method vary as compared with the other? For example, is one method less secure than the other?

Response

Please enter the differences starting on the next blank line below. If there is no difference in effect between the two methods of deleting security context, then simply enter the following text: The effect is the same, whichever of the two methods is used to delete security context.

Rationale

See Question 8 above.

Reference

See Question 8 above.

2. Appendix

Copyright © 
All rights reserved.

3. Change History