WDIFF

draft-ietf-cat-snego-03.txt --> draft-ietf-cat-snego-04.txt

Internet-Draft Eric Baize, Denis Pinkas
IETF Common Authentication Technology WG Bull
<draft-ietf-cat-snego-03.txt> 25 March
<draft-ietf-cat-snego-04.txt> 22 April 1997

The Simple and Protected GSS-API Negotiation Mechanism

STATUS OF THIS MEMO

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Comments on this document should be sent to "cat-ietf@mit.edu", the
IETF Common Authentication Technology WG discussion list. Distribution
of this document is unlimited.

2. ABSTRACT

This draft document specifies a Security Negotiation Mechanism for the
Generic Security Service Application Program Interface (GSS-API) which
is described in [1].

The GSS-API provides a generic interface which can be layered atop
different security mechanisms such that if communicating peers acquire
GSS-API credentials for the same security mechanism, then a security
context may be established between them (subject to policy). However,
GSS-API doesn't prescribe the method by which GSS-API peers can
establish whether they have a common security mechanism.

The Simple and Protected GSS-API Negotiation Mechanism defined here
is a pseudo-
security pseudo-security mechanism, represented by the object identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
enables GSS-API peers to determine in-band whether their credential credentials
share common GSS-API security mechanism(s), and if so, to invoke
normal security context establishment for a selected common security
mechanism. This is most useful for applications that are based on
GSS-API implementations which support multiple security mechanisms.

Baize, Pinkas Document Expiration: 25 September 22 October 1997 [Page 1]
Internet-Draft March 25, April 22, 1997

As most existing GSS-API security mechanisms can support different
options (such as differing cryptographic algorithms due to policy or
legislative constraints), the Simple and Protected GSS-API Negotiation
Mechanism allows to negotiate security mechanisms including their
options (i.e. variants). Mechanism options can be considered as
providing a type of "quality of protection" for security contexts.

To facilitate mechanism negotiation, the OID which currently defines a
security mechanism is "extended" to be able to specify options within a
security mechanism rather than simply the basic mechanism. When the OID
specifies the mechanism only and no explicit option, then this means
that the default option is used. The default option and the specific
options for a given mechanism are as defined in the IETF GSS-API
specification(s) for the mechanism.

This allows to negotiate basic security mechanisms, different options
within a given security mechanism or different options from several
basic security mechanisms.

In addition, a given security mechanism may still negotiate mechanism-
specific options during the context establishment for that mechanism,
i.e. after the mechanism has been selected by the negotiation process.

The simple and protected GSS-API mechanism negotiation is based on a two-ways the
following negotiation model : The the initiator proposes one or several
security mechanisms, the target either accepts the proposed security
mechanism, or chooses one from an offered set, or rejects the proposed
value(s). The target informs the initiator of its choice and may also
return mechanism specific information related to the chosen mechanism.

In its basic form this protocol requires an extra-round trip. Network
connection setup is a critical performance characteristic of any
network infrastructure and extra round trips over WAN links, packet
radio networks, etc. really make a difference. In order to avoid such
an extra round trip the initial security token of the preferred
mechanism for the initiator may be embedded in the initial token.
If the target preferred mechanism matches the initiator's preferred
mechanism, no additional round trips are incurred by using the
negotiation protocol.

The simple and protected GSS-API mechanism negotiation does not provide any security
feature provides a
technique to protect the initially exchanged values for security context
parameters (i.e. during the negotiation process). This implies that all
negotiated mechanisms including their options should must be used when the
underlying mechanism selected by the target is capable of integrity
protection.

When all the same
strength. mechanisms proposed by the initiator support integrity
protection or when the selected mechanism supports integrity
protection, then the negotiation mechanism becomes protected since
this guarantees that the appropriate mechanism supported by both
peers has been selected.

Baize, Pinkas Document Expiration: 22 October 1997 [Page 2]
Internet-Draft April 22, 1997

The Simple and Protected GSS-API Negotiation Mechanism uses the
concepts developed in GSS-API specification [1], and requires the use
of a new GSS-API context-level token tokens : the negotiation token. tokens. Callers
of the GSS-API do not need to be aware of the existence of the
negotiation token tokens but only of the new pseudo-security mechanism.
A failure in the negotiation phase causes a major status code to be
returned: GSS_S_BAD_MECH.

Baize, Pinkas Document Expiration: 25 September 1997 [Page 2]
Internet-Draft March 25, 1997

3. NEGOTIATION MODEL

3.1. Negotiation description

The model for security mechanism negotiation reuses a subset of the
concepts specified in [2].

Each security mechanism represents one basic security mechanism along
with one option for this security mechanism (when no option is present
the default option is assumed).

- When one security mechanism is proposed by the initiator, it
represents the only security mechanism option supported or
selected (when the additional APIs defined in the Annex A
are used) by the initiator.

- When several security mechanisms are proposed by the initiator,
they represent a set of security mechanisms supported or selected
(when the additional APIs defined in the Annex A are used) by the
initiator.

The initiator first negotiation token sent by the initiator contains an ordered
list of mechanisms and optionally the initial security token for the
desired mechanism of the initiator (i.e. the first of the list).

The target first negotiation reply token sent by the target contains the result of
the negotiation (accept or reject) and, in case of accept, the agreed
security mechanism along with optional mechanism specific information.
It may also include the response to the initial security token, token for the
desired mechanism of the initiator, when the first proposed mechanism
has been selected. Not all targets must be able to respond to the
initial security token for the desired mechanism when it is present.
The target can simply ignore it and complete the negotiation handshake without
it. Implementations that can piggyback the initial token will be
rewarded by faster connection setup.

In case of a successful negotiation, the security mechanism represents
the value suitable for the target, and picked up from the list offered
by the initiator. The target selects the value according to a simple
selection criteria: it checks if the first entry from its own list is
present in the set offered by the initiator. If the entry is present,
then it is the agreed mechanism, if not then the second entry from its
own ordered list is checked and the process continues until all
entries have been checked. Thus, the target's mechanism preferences
have precedence when more than one common mechanism is available
between the target and initiator.

Baize, Pinkas Document Expiration: 22 October 1997 [Page 3]
Internet-Draft April 17, 1996

3.2. Negotiation procedure

The negotiation procedure is summarised as follows:

(a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
requests (either explicitly, with the negotiation mechanism, or
through accepting a default, when the default is the negotiation
mechanism) that the Simple and Protected GSS-API Negotiation Mechanism
be used;

Baize, Pinkas Document Expiration: 25 September 1997 [Page 3]
Internet-Draft April 17, 1996

b) the initiator GSS-API implementation emits a negotion negotiation token
containing the set of supported security mechanism for the credentials
used for this context establishment, and optionally the initial
security token for the preferred mechanism, and indicates
GSS_CONTINUE_NEEDED status;

(d) The GSS-API target deposits the token through invoking
GSS_Accept_sec_context. The target GSS-API implementation emits a
negotiation token containing which if any of the proposed mechanisms
it supports (or has selected).

If the preferred mechanism selected by the target matches the preferred
mechanism identified by the initiator and the initiator provides a
preferredToken, the negotiation token response may contain also the
initial security token from that mechanism.

If the preferred mechanism is accepted, GSS_Accept_sec_context()
indicates GSS_COMPLETE when unilateral or mutual authentication has
been performed and involves a single token. token in either direction.

If the proposed mechanism(s) are accepted, or the preferred mechanism
is accepted but involves multiple exchanges (e.g. mutual challenge-response
authentication), then GSS_Accept_sec_context()indicates
GSS_CONTINUE_NEEDED status.

If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
indicates GSS_S_BAD_MECH status. The security context initialisation
has failed.

(e) The GSS-API target returns the token to the initiator application;

(f) The GSS-API initiator deposits the token through invoking
GSS_Init_sec_context.

GSS_Init_sec_context() may then indicate GSS_CONTINUE_NEEDED,
GSS_COMPLETE or GSS_S_BAD_MECH status.

The GSS_S_BAD_MECH status is returned when the negotiation token
carries a reject result or when the negotiation token carries an
accept result,
GSS_Init_sec_context() returns an initial context token as
output_token, result and indicates GSS_CONTINUE_NEEDED or GSS_COMPLETE
status. The initiator sends the output_token to mechanism selected by the target. The
security context initialisation target is then performed according to the
standard GSS-API conventions for not
included in the selected mechanism. When
GSS_COMPLETE is returned, initial list sent by the mech_type output parameter indicates initiator or the

Baize, Pinkas Document Expiration: 22 October 1997 [Page 4]
Internet-Draft April 22, 1997

selected mechanism. Since mechanism supports a MIC token but the negotiation exchanges are not crypto-
graphically protected, the initiator GSS-API implementation must check MIC computed over
the returned/selected mechanism options with its originally submitted list of mechanism options. When GSS_CONTINUE_NEEDED is returned, mechanisms sent by the
mech_type output parameter initiator is not yet valid.

Note that the *_req_flag input parameters for context establishment
are relative to the selected mechanism, as are the *_state output
parameters. i.e., these parameters are not applicable to the
negotiation process per se.

Baize, Pinkas Document Expiration: 25 September 1997 [Page 4]
Internet-Draft March 25, 1997 missing or
incorrect. If the negotiation token carries a reject result, the
context establishment is impossible, and GSS_Init_sec_context() indicates
GSS_S_BAD_MECH status. impossible. For example, a rejection
will occur if the target doesn't support the initiator's proposed
mechanism type(s) and/or mechanism option(s). Upon failure of the
mechanism negotiation procedure, the mech_type output parameter
value is the negotiation mechanism type. However, upon failure

The GSS_CONTINUE_NEEDED status is returned when the negotiation
token carries an accept result. In that case
GSS_Init_sec_context() returns an initial context token as
output_token. The initiator then sends the output_token to the
target. The security context initialisation is then continued
according to the standard GSS-API conventions for the selected
mechanism, where the tokens of the selected mechanism
context establishment, are
encapsulated until the GSS_COMPLETE is returned for both the
initiator and the target. When GSS_CONTINUE_NEEDED is returned,
the mech_type output parameter value is not yet valid.

When GSS_COMPLETE is returned, the mech_type output parameter
indicates the selected mechanism. When the final negotiation token
does not contain a MIC, the initiator GSS-API implementation must
check the returned/selected mechanism type. options with its originally
submitted list of mechanism options and also verify that the
selected mechanism is not able to support a MIC. When the final
negotiation token contains a MIC over the initial mechanisms list
sent by the initiator, the MIC must be verified.

The initiator GSS-API calling application may know when the
negotiation exchanges were protected or not. For this, when
GSS_COMPLETE is returned, it can simply test the integ_avail flag.
When this flag is set it indicates that the negotiation was protected.

On receipt of a negotiation token on the target side, a GSS-API
implementation that does not support negotiation would indicate the
GSS_FAILURE status as if a particular basic security mechanism had
been requested but was not supported.

When GSS_Acquire_cred is invoked with the negotiation mechanism as
desired_mechs, an implementation-specific default credential is used to
carry on the negotiation. A set of mechanisms as specified locally by the
system administrator is then available for negotiation. If there is a
desire for the caller to make its own choice, then an additional API has to
be used (see Appendix A).

Baize, Pinkas Document Expiration: 22 October 1997 [Page 5]
Internet-Draft April 22, 1997

4. DATA ELEMENTS

4.1. Mechanism Type

MechType::= OBJECT IDENTIFIER

mechType
The concept of mechType is extended to specify a basic security
mechanism including its options. Each basic security mechanism
is as defined in [1], and must provide a single default option
which fully specifies the mechanism. The default option is
represented by the OID of the mechanism itself (i.e. without any
extension).

The options are specified by extending the OID. This
extension is defined in the same IETF GSS-API specification as
the security mechanism context token specification.

4.2. Negotiation Token Tokens

The negotiation token syntax of the negotiation tokens follows the InitialContextToken
syntax defined in [1]. The security mechanism of the initial
negotiation token is identified by the Object Identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).

4.2.1. Syntax

This section specifies the syntax of the corresponding
"innerContextToken" field. field for the first token and subsequent
negotiation tokens.

NegotiationToken ::= CHOICE {
negTokenReq
negTokenInit [0] NegTokenReq,
negTokenRep NegTokenInit,
negTokenTarg [1] NegTokenRep NegTokenTarg }

MechType ::= OBJECT IDENTIFIER

Baize, Pinkas Document Expiration: 25 September 1997 [Page 5]
Internet-Draft March 25, 1997

MechTypeList ::= SEQUENCE OF MechType

NegTokenReq

NegTokenInit ::= SEQUENCE {
mechTypes[0] MechTypeList,
preferredToken[1]
mechTypes [0] MechTypeList OPTIONAL
preferredToken [1] OCTET STRING OPTIONAL
}

negTokenReq

negTokenInit
Negotiation token sent by the initiator to the target, which contains
contains, for the first token sent, one or more security
mechanisms supported by the initiator. The preferredToken is an
optional field in of the request first token sent that all target
implementations would not have to support. However for those
targets that do support piggybacking the initial preferredToken,
an optimistic negotiation response is possible.

negTokenRep

Baize, Pinkas Document Expiration: 22 October 1997 [Page 6]
Internet-Draft April 22, 1997

NegTokenTarg ::= SEQUENCE {
negResult [0] ENUMERATED { accept (0), reject (1) } OPTIONAL
supportedMech [1] MechType OPTIONAL
MechSpecInfo [2] OCTET STRING OPTIONAL
preferredToken [3] OCTET STRING OPTIONAL
mechListMIC [4] OCTET STRING OPTIONAL
}

negTokenTarg
Negotiation token returned by the target to the initiator which contains
contains, for the first token returned, a global negotiation
result, the security mechanism selected (if any) and optional
information specific to the security mechanism selected by the
target. For those targets that support piggybacking the initial
preferredToken, an optimistic negotiation response is possible
and includes in that case a preferredToken which may continue
the authentication exchange (e.g. when mutual authentication has
been requested or when unilateral authentication requires several
round trips).

NegTokenRep ::= SEQUENCE {
negResult [0] ENUMERATED { accept (0), reject (1) }
supportedMech [1] MechType OPTIONAL
MechSpecInfo [2] OCTET STRING OPTIONAL Otherwise the preferredToken [3] OCTET STRING OPTIONAL
} is used to carry the
tokens specific to the mechanism selected. For the last token
returned by the target, the mechListMIC is a MIC computed over
the MechTypes using the selected mechanism.

negResult
Result of the negotiation exchange, specified by the target.
This can be either :
accept
The target accepts one of the proposed
security mechanisms, or,
reject
The target rejects all the proposed security
mechanisms.

supportedMech
This field has to be present when negResult is "accept".
It is a choice from the mechanisms offered by the initiator.

MechSpecInfo
This field may be used to transmit mechanism specific
information relative to the security mechanism selected
by the target.

preferredToken
This field may be used either to transmit the response to the
preferredToken when sent by the initiator and when the first
mechanism from the list has been selected by the target or
to carry the tokens specific to the selected security mechanism.

mechListMIC
If the selected mechanism is capable of integrity protection,
this field must be present in the last message of the negotiation,
(i.e., when the underlying mechanism returns a non-empty token

Baize, Pinkas Document Expiration: 25 September 22 October 1997 [Page 6] 7]
Internet-Draft March 25, April 22, 1997

preferredToken
This

and a major status of GSS_COMPLETE); it contains the result of a
GetMIC of the MechTypes field may in the initial NegTokenInit.

4.2.2. Processing of mechListMIC.

When the mechanism selected by the negotiation supports integrity
protection as a service, the mechListMIC must be used to transmit and validated.

In particular, the response to target that sends the last context establishment
token must also include the result of a gss_get_mic() of the
preferedToken when
mechTypeList sent by the initiator and when in the first
mechanism from token; in addition,
the list has been selected by initiator that receives the target. last token must require that the
mechListMIC field be present and valid. In the absence of a valid
mechListMIC, the negotiation must fail as if the last context
establishment token was invalid.

5. EXAMPLES : SECURITY MECHANISM NEGOTIATION

Follow some examples of security mechanism options negotiation between
an initiator (I) and a target (T).

5.1. Initial steps

(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2.

(I) invokes GSS_Init_sec_context() with :

Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.

Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenReq negTokenInit

The negotiation token (negTokenReq) (negTokenInit) contains three security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2-OPTION1 or
mechType = GSS-MECH2-OPTION2

(I) sends to (T) the negotiation token.

5.2 Successful negotiation steps

(T) supports GSS-MECH2-OPTION1.
(T) receives the negotiation token (negTokenReq) (negTokenInit) from (I)
(T) invokes GSS_Accept_sec_context() with :

Baize, Pinkas Document Expiration: 22 October 1997 [Page 8]
Internet-Draft April 22, 1997

Input
input_token = negTokenReq negTokenInit

Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenRep negTokenTarg

The negotiation token (negTokenRep) (negTokenTarg) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH2-OPTION1

Baize, Pinkas Document Expiration: 25 September 1997 [Page 7]
Internet-Draft March 25, 1997

(T) returns the negotiation token (negTokenRep) (negTokenTarg) to (I)
(I) invokes GSS_Init_sec_context() with :

Input
input_token = negTokenRep negTokenTarg

Output
major_status = GSS_COMPLETE
output_token = initialContextToken (initial context token
for GSS-MECH2-OPTION1)
mech_type = GSS-MECH2-OPTION1

The subsequent steps are security mechanism specific, and works work as
specified in [1]. The output tokens from the security mechanism are
encapsulated in a NegTokenTarg message (with the supportedMech and
MechSpecInfo fields omitted, and the mechListMIC included with the
last token).

5.3. Failed negotiation steps

(T) supports GSS-MECH3.
(T) receives the negotiation token (negTokenReq) (negTokenInit) from (I)
(T) invokes GSS_Accept_sec_context() with :

Input
input_token = negTokenReq negTokenInit

Output
major_status = GSS_S_BAD_MECH
output_token = negTokenRep negTokenTarg

The negotiation token (negTokenRep) (negTokenTarg) contains :

negResult = reject (the negotiation result)

(T) returns the negotiation token (negTokenRep) (negTokenTarg) to (I)
(I) invokes GSS_Init_sec_context() with :

Input
input_token = negTokenRep negTokenTarg

Baize, Pinkas Document Expiration: 22 October 1997 [Page 9]
Internet-Draft April 22, 1997

Output
major_status = GSS_S_BAD_MECH

The security context establishment has failed.

5.4 Successful Negotiation with preferred mechanism info

(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2.

(I) invokes GSS_Init_sec_context() with :

Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.

Baize, Pinkas Document Expiration: 25 September 1997 [Page 8]
Internet-Draft March 25, 1997

Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenReq negTokenInit

The negotiation token (negTokenReq) (negTokenInit) contains three security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2-OPTION1 or
mechType = GSS-MECH2-OPTION2

preferredToken = output_token from GSS_Init_sec_context
( first mechType) as described in [1]

(I) sends to (T) the negotiation token.

(T) supports GSS-MECH1.
(T) receives the negotiation token (negTokenReq) (negTokenInit) from (I)
(T) invokes GSS_Accept_sec_context() with :

Input
input_token = negTokenReq negTokenInit

Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenRep negTokenTarg

The negotiation token (negTokenRep) (negTokenTarg) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH1
MechSpecInfo = mechanism specific information for
the preferred mechanism
preferredToken = output_token from
GSS_Accept_sec_context(preferredToken )

Baize, Pinkas Document Expiration: 22 October 1997 [Page 10]
Internet-Draft April 22, 1997

(T) returns the negotiation token (negTokenRep) (negTokenTarg) to (I)
(I) invokes GSS_Init_sec_context() with :

Input
input_token = negTokenRep negTokenTarg

Output
major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed
output_token = ContextToken (initial or subsequent context token
for GSS-MECH1)
mech_type = GSS-MECH1

Specific implementations of the protocol can support the optimistic
negotiation by completing the security context establishment using the
agreed upon mechanism as described in [1]

Baize, Pinkas Document Expiration: 25 September 1997 [Page 9]
Internet-Draft March 25, 1997 [1]. As described above in
section 5.2, the output tokens from the security mechanism are
encapsulated in a NegTokenTarg message (with the negResult,
supportedMech and MechSpecInfo fields omitted, and the mechListMIC
included with the last token).

6. ACKNOWLEDGEMENTS

Acknowledgement ACKNOWLEDGMENTS

Acknowledgments are due to Piers McMahon and Tom Parker of ICL,
Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of
Openvision for reviewing earlier versions of this document and for
providing useful inputs. A special acknowledgment for Acknowledgments are also due to Peter Brundrett
of Microsoft for his proposal for an optimistic negotiation, and for
Bill Sommerfeld of Hewlett-Packard for his proposal for protecting
the negotiation.

7. SECURITY CONSIDERATIONS

The purpose of the generic simple GSS-API mechanism negotiation
mechanism is to enable peers to agree on the value for a security
mechanism and security related options required for initialising
security services.

As this

When the mechanism selected by the target from the list supplied by
the initiator supports integrity protection, then the negotiation is called prior to any initialisation of a security
service, it cannot make use
protected.

When one of any security feature. Therefore it the mechanisms proposed by the initiator does not support
integrity protection, then the negotiation is exposed to all threats a non
secured service is exposed.

Communicating peers may be exposed to the denial of service threat, or
can be forced by In particular, an active attacker can force to
use a security mechanism which is not their the common preferred one (when
multiple security mechanisms are shared between peers) but which is
acceptable anyway to the target. This implies that all negotiated mechanisms including their
options should

In any case, the communicating peers may be of exposed to the same strength. denial of
service threat.

Baize, Pinkas Document Expiration: 25 September 22 October 1997 [Page 10] 11]
Internet-Draft March 25, April 22, 1997

APPENDIX A

GSS-API NEGOTIATION SUPPORT API

In order to provide to a GSS-API caller (either the initiator or the
target or both) the ability to choose among the set of supported
mechanisms a reduced set of mechanisms for negotiation, two
additionnal
additional APIs are defined:

GSS_Get_neg_mechs() indicates the set of security mechanisms available
on the local system to the caller for negotiation.

GSS_Set_neg_mechs() specifies the set of security mechanisms to be
used on the local system by the caller for negotiation.

A.1. GSS_Get_neg_mechs call

Input:
cred_handle OCTET STRING - NULL specifies default credentials

Outputs:
major_status INTEGER,
minor_status INTEGER,
mech_option_set SET OF OBJECT IDENTIFIER

Return major_status codes :
GSS_COMPLETE indicates that the set of security mechanism
options available for negotiation has been returned in
mech_option_set.
GSS_FAILURE indicates that the requested operation could not
be performed for reasons unspecified at the GSS-API level.

Allows callers to determine the set of security mechanism options
available for negotiation. This call is intended for support of
specialised callers who need to reduce the set of negotiable security
mechanism options from the set of supported security mechanisms
available to the caller (based on available credentials).

Note: The GSS_Indicate_mechs() function indicates the full set of mechanism
types available on the local system. Since this call does not use a
credential handle as an input parameter, the returned set is not
necessarily available for all credentials.

Baize, Pinkas Document Expiration: 25 September 22 October 1997 [Page 11] 12]
Internet-Draft March 25, April 22, 1997

A.2. GSS_Set_neg_mechs call

Input:
cred_handle OCTET STRING - NULL specifies default credentials
mech_option_set SET OF OBJECT IDENTIFIER

Outputs:
major_status INTEGER,
minor_status INTEGER,

Return major_status codes :
GSS_COMPLETE indicates that the set of security mechanisms
available for negotiation has been set to mech_option_set.
GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.

Allows callers to specify the set of security mechanism options that
may be negotiated: negotiated with a particular credential: A NULL mech_option_set
specifies that only the default mech_type with the default option is
available for the GSS-API implementation. This call is intended for
support of specialised callers who need to restrict the set of
negotiable security mechanism options from the set of all security
mechanism options available to the caller (based on available
credentials). Note that if more than one mechanism is specified in
mech_option_set, the order in which those mechanisms are specified
implies a relative mechanism preference for the target.

REFERENCES

[1] Linn, J., "Generic Security Service Application Program
Interface", RFC 1508, 2078, OpenVision, September 1993. January 1997. Available on
ftp://ds.internic.net/rfc/rfc2078.txt

[2] Standard ECMA-206, "Association Context Management including
Security Context Management", December 1993. Available on
http://www.ecma.ch

AUTHORS'S ADDRESSES

Eric Baize Internet email: E.Baize@ma02.bull.com
Bull HN - MA02/211S Phone: +1 508 294 61 37
Technology Park Fax: +1 508 294 61 09
Billerica, MA 01821 - USA

Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr
Bull Phone: +33 1 30 80 34 87
Rue Jean-Jaures Fax: +33 1 30 80 33 21
BP 68
78340 Les Clayes-sous-Bois - FRANCE

Baize, Pinkas Document Expiration: 25 September 22 October 1997 [Page 12] 13]

----