GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2478

Network Working Group E. Baize Request for Comments: 2478 D. Pinkas Category: Standards Track Bull

                                                       December 1998
       The Simple and Protected GSS-API Negotiation Mechanism

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1998).  All Rights Reserved.

1. ABSTRACT

 This 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 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 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.
 This allows to negotiate different security mechanisms, different
 options within a given security mechanism or different options from
 several security mechanisms.

Baize & Pinkas Standards Track [Page 1] RFC 2478 GSS-API Negotiation Mechanism December 1998

 Once the common security mechanism is identified, the security
 mechanism may also negotiate mechanism-specific options during its
 context establishment. This will be inside the mechanism tokens, and
 invisible to the SPNEGO protocol.
 The simple and protected GSS-API mechanism negotiation is based on
 the following negotiation model : the initiator proposes one security
 mechanism or an ordered list of 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 then
 informs the initiator of its choice.
 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 provides a
 technique to protect the negotiation that must be used when the
 underlying mechanism selected by the target is capable of integrity
 protection.
 When all the 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.
 The Simple and Protected GSS-API Negotiation Mechanism uses the
 concepts developed in the GSS-API specification [1]. The negotiation
 data is encapsulated in context-level tokens. Therefore, callers of
 the GSS-API do not need to be aware of the existence of the
 negotiation 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 Standards Track [Page 2] RFC 2478 GSS-API Negotiation Mechanism December 1998

2. NEGOTIATION MODEL

2.1. Negotiation description

 The model for security mechanism negotiation reuses a subset of the
 concepts specified in [2].
 Each OID represents one GSS-API mechanism or one variant of it.
  1. When one security mechanism is proposed by the initiator, it

represents the only security mechanism supported or selected

     (when the additional APIs defined in the Annex A are used) by the
     initiator.
  1. 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 first negotiation token sent by the initiator contains an ordered
 list of mechanisms, a set of options (e.g. deleg, replay, conf flags)
 that should be supported by the selected mechanism and optionally the
 initial security token for the desired mechanism of the initiator
 (i.e. the first of the list).
 The first negotiation token sent by the target contains the result of
 the negotiation (accept_completed, accept_incomplete or reject) and,
 in case of accept, the agreed security mechanism. It may also include
 the response to the initial security token from the initiator, when
 the first proposed mechanism of the initiator has been selected. When
 the first mechanism is acceptable to the target,it should respond to
 the initial security token for the desired mechanism of the initiator
 when it is present. However, if this is not possible, the target can
 simply ignore it and omit the responseToken from the first reply.
 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 policy by which the target
 chooses a mechanism is an implementation-specific local matter.  In
 the absence of other policy, the target should chose the first
 mechanism in the list for which valid credentials are available.
 Once a mechanism has been selected, the tokens specific to the
 selected mechanism are carried within the negotiation tokens (in the
 mechToken for the initiator and in the responseToken for the target).

Baize & Pinkas Standards Track [Page 3] RFC 2478 GSS-API Negotiation Mechanism December 1998

2.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;
 (b) the initiator GSS-API implementation emits a negotiation token
     containing a list of supported security mechanisms for the
     credentials used for this context establishment, and optionally
     an initial security token for the first mechanism from that list
     (i.e. the preferred mechanism), and indicates
     GSS_S_CONTINUE_NEEDED status;
 (c) The GSS-API initiator sends the token to the target application;
 (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 mechanism selected by the target matches the preferred
 mechanism identified by the initiator and the initiator provides a
 mechToken, the negotiation token response may contain also an initial
 security token from that mechanism.
 If the preferred mechanism is accepted, GSS_Accept_sec_context()
 indicates GSS_S_COMPLETE when unilateral or mutual authentication has
 been performed and involves a single token in either direction.
 If a proposed mechanism is accepted, and it was not the preferred
 mechanism, or if the first negotiation token sent by the initiator
 did not included a mechToken, then the negotiation token response
 sent by the target may contain also a response token from that
 mechanism which transmits mechanism-specific information (e.g. to
 transmit a certificate). The initiator may ignore such an initial
 token if it is not prepared to process it.
 If a proposed mechanism other than the preferred mechanism is
 accepted, or the preferred mechanism is accepted but involves
 multiple exchanges (e.g. challenge-response authentication), then
 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.

Baize & Pinkas Standards Track [Page 4] RFC 2478 GSS-API Negotiation Mechanism December 1998

 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_S_CONTINUE_NEEDED,
 GSS_S_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 and the mechanism selected by the target is not
    included in the initial list sent by the initiator.
    The GSS_S_BAD_MIC status is returned when the selected mechanism
    supports a MIC token but the MIC computed over the list of
    mechanisms sent by the initiator is missing or incorrect.
    If the negotiation token carries a reject result, the context
    establishment is impossible. For example, a rejection will occur
    if the target doesn't support the initiator's proposed mechanism
    type(s). Upon failure of the mechanism negotiation procedure, the
    mech_type output parameter value is the negotiation mechanism
    type.
    The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
    token carries an accept result and further tokens must be
    transferred in order to complete context establishment for the
    selected mechanism. In that case GSS_Init_sec_context() returns an
    initial context token as output_token (with the selected
    mechanism's context token encapsulated within that 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 are encapsulated until the
    GSS_S_COMPLETE is returned for both the initiator and the target.
    When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
    parameter is not yet valid.
    When GSS_S_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 is on the originally

Baize & Pinkas Standards Track [Page 5] RFC 2478 GSS-API Negotiation Mechanism December 1998

    submitted list of mechanisms 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.
 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.
 The initiator GSS-API calling application may need to know when the
 negotiation exchanges were protected or not. For this, when
 GSS_S_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_S_BAD_MECH 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).

3. DATA ELEMENTS

3.1. Mechanism Type

 MechType::= OBJECT IDENTIFIER
 mechType
      Each security mechanism is as defined in [1].

3.2. Negotiation Tokens

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

Baize & Pinkas Standards Track [Page 6] RFC 2478 GSS-API Negotiation Mechanism December 1998

3.2.1. Syntax

 This section specifies the syntax of the corresponding
 "innerContextToken" field for the first token and subsequent
 negotiation tokens. During the mechanism negociation, the
 "innerContextToken" field contains the ASN.1 structure
 "NegociationToken" given below, encoded using the DER encoding
 conventions.

NegotiationToken ::= CHOICE {

                            negTokenInit  [0]  NegTokenInit,
                            negTokenTarg  [1]  NegTokenTarg }

MechTypeList ::= SEQUENCE OF MechType

NegTokenInit ::= SEQUENCE {

                          mechTypes       [0] MechTypeList  OPTIONAL,
                          reqFlags        [1] ContextFlags  OPTIONAL,
                          mechToken       [2] OCTET STRING  OPTIONAL,
                          mechListMIC     [3] OCTET STRING  OPTIONAL
                       }

ContextFlags ::= BIT STRING {

      delegFlag       (0),
      mutualFlag      (1),
      replayFlag      (2),
      sequenceFlag    (3),
      anonFlag        (4),
      confFlag        (5),
      integFlag       (6)

}

negTokenInit

   Negotiation token sent by the initiator to the target, which
   contains, for the first token sent, one or more security mechanisms
   supported by the initiator (as indicated in the field mechTypes)
   and the service options (reqFlags) that are requested to establish
   the context. The context flags should be filled in from the
   req_flags parameter of init_sec_context().
   The mechToken field is optional for the first token sent that all
   target implementations would not have to support. However for those
   targets that do support piggybacking the initial mechToken, an
   optimistic negotiation response is possible. Otherwise the
   mechToken is used to carry the tokens specific to the mechanism
   selected.

Baize & Pinkas Standards Track [Page 7] RFC 2478 GSS-API Negotiation Mechanism December 1998

   The mechListMIC is an optional field. In the case that the chosen
   mechanism supports integrity, the initiator may optionally include
   a mechListMIC which is the result of a GetMIC of the MechTypes in
   the initial NegTokenInit and return GSS_S_COMPLETE.
   When the chosen mechanism uses an odd number of messages, the final
   mechanism token will be sent from the initiator to the acceptor. In
   this case, there is a tradeoff between using the optimal number of
   messages, or using an additional message from the acceptor to the
   initiator in order to give the initiator assurance that no
   modification of the initiator's mechanism list occurred. The
   implementation can choose which tradeoff to make (see section 4.2.2
   for further details for the processing of that field).

NegTokenTarg ::= SEQUENCE {

  negResult      [0] ENUMERATED {
                          accept_completed    (0),
                          accept_incomplete   (1),
                          reject              (2) }          OPTIONAL,
  supportedMech  [1] MechType                                OPTIONAL,
  responseToken  [2] OCTET STRING                            OPTIONAL,
  mechListMIC    [3] OCTET STRING                            OPTIONAL

}

negTokenTarg

   Negotiation token returned by the target to the initiator which
   contains, for the first token returned, a global negotiation result
   and the security mechanism selected (if any).

negResult

   The result accept_completed indicates that a context has been
   successfully established, while the result accept_incomplete
   indicates that additional token exchanges are needed.
        Note: For the case where (a) a single-token context setup is
        used and (b) the preferred mechanism does not support the
        integrity facility which would cause a mechListMIC to be
        generated and enclosed, this feature allows to make a
        difference between a mechToken sent by the initiator but not
        processed by the target (accept_incomplete) and a mechToken
        sent by the initiator and processed by the target
        (accept_completed).
   For those targets that support piggybacking the initial mechToken,
   an optimistic negotiation response is possible and includes in that
   case a responseToken which may continue the authentication exchange
   (e.g. when mutual authentication has been requested or when
   unilateral authentication requires several round trips). Otherwise

Baize & Pinkas Standards Track [Page 8] RFC 2478 GSS-API Negotiation Mechanism December 1998

   the responseToken is used to carry the tokens specific to the
   mechanism selected. For subsequent tokens (if any) returned by the
   target, negResult, and supportedMech are not present.
   For the last token returned by the target, the mechListMIC, when
   present, 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_completed
             The target accepts the preferred security mechanism,
              and the context is established for the target or,
        accept_incomplete
             The target accepts one of the proposed security
             mechanisms and further exchanges are necessary, or,
        reject
             The target rejects all the proposed security
             mechanisms.

supportedMech

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

responseToken

   This field may be used either to transmit the response to the
   mechToken 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 and
   a major status of GSS_S_COMPLETE); it contains the result of a
   GetMIC of the MechTypes field in the initial NegTokenInit.  It
   allows to verify that the list initially sent by the initiator has
   been received unmodified by the target.

Baize & Pinkas Standards Track [Page 9] RFC 2478 GSS-API Negotiation Mechanism December 1998

3.2.2. Processing of mechListMIC.

 If the mechanism selected by the negotiation does not support
 integrity, then no mechListMIC is included, otherwise a mechListMIC
 must be used and validated as indicated below.
 If the mechanism supports integrity and uses an even number of
 messages, then the target must compute a MIC as described above, and
 send this in the final NegTokenTarg along with the final mechToken.
 The initiator when receiving the 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.
 In the case that the chosen mechanism supports integrity and uses an
 odd number of messages, the final mechanism token will be sent from
 the initiator to the target. In this case, there is a tradeoff
 between using the optimal number of messages, or using an additional
 message from the target to the initiator in order to give the
 initiator assurance that no modification of the initiator's mechanism
 list occurred. The implementation can choose which tradeoff to make.
 When generating the final NegTokenInit message, the NegTokenInit may
 optionally include a mechListMIC which is the result of a GetMIC of
 the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
 The target must check the presence of the MIC computed over the
 mechList sent in the initial NegTokenInit. Three cases may then be
 considered:
    1) If the mechListMIC is present and correct, then
       GSS_S_COMPLETE is returned to the target with no token; the
       context is established by the target.
    2) If the mechListMIC is present but invalid, then the context
       establishment must fail.  An error major status code is
       returned to the target.
    3) If the mechListMIC is not included in the final NegTokenInit,
       then GSS_S_COMPLETE must be returned to the target with a
       token. This token must be a NegTokenTarg, with a MIC included
       as described above, and no responseToken.  The application will
       then send this token back to the initiator, which must verify
       that the mechListMIC field is present and valid.

Baize & Pinkas Standards Track [Page 10] RFC 2478 GSS-API Negotiation Mechanism December 1998

       Note: If the MIC was originally sent by the initiator, but
              thenafter deleted by an attacker, the target will send
              back a token according to the description above, but the
              initiator will be unable to process that returned token
              and the context establishment must then fail.

4. EXAMPLES : SECURITY MECHANISM NEGOTIATION

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

4.1. Initial steps

 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
 (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_S_CONTINUE_NEEDED
   output_token = negTokenInit
 The negotiation token (negTokenInit) contains two security mechanisms
 with :
   mechType = GSS-MECH1 or
   mechType = GSS-MECH2
 (I) sends to (T) the negotiation token.

4.2 Successful negotiation steps

 (T) supports GSS-MECH2
 (T) receives the negotiation token (negTokenInit) from (I)
 (T) invokes GSS_Accept_sec_context() with :
 Input
      input_token = negTokenInit
 Output
      major_status = GSS_S_CONTINUE_NEEDED
      output_token = negTokenTarg
 The negotiation token (negTokenTarg) contains :
      negResult = accept (the negotiation result)
      supportedMech : mechType = GSS-MECH2

Baize & Pinkas Standards Track [Page 11] RFC 2478 GSS-API Negotiation Mechanism December 1998

 (T) returns the negotiation token (negTokenTarg) to (I)
 (I) invokes GSS_Init_sec_context() with :
 Input
      input_token = negTokenTarg
 Output
      major_status = GSS_S_COMPLETE
      output_token = initialContextToken (initial context token
                                          for GSS-MECH2)
      mech_type = GSS-MECH2
 The subsequent steps are security mechanism specific, and work as
 specified in [1].  The output tokens from the security mechanism are
 encapsulated in a NegTokenTarg message (with the supportedMech field
 omitted, and the mechListMIC included with the last token).

4.3. Failed negotiation steps

 (T) supports GSS-MECH3.
 (T) receives the negotiation token (negTokenInit) from (I)
 (T) invokes GSS_Accept_sec_context() with :
 Input
      input_token = negTokenInit
 Output
      major_status = GSS_S_BAD_MECH
      output_token = negTokenTarg
 The negotiation token (negTokenTarg) contains :
      negResult = reject (the negotiation result)
 (T) returns the negotiation token (negTokenTarg) to (I)
 (I) invokes GSS_Init_sec_context() with :
 Input
      input_token = negTokenTarg
 Output
      major_status = GSS_S_BAD_MECH
 The security context establishment has failed.

Baize & Pinkas Standards Track [Page 12] RFC 2478 GSS-API Negotiation Mechanism December 1998

4.4 Successful Negotiation with preferred mechanism info

 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
 (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_S_CONTINUE_NEEDED
      output_token = negTokenInit
 The negotiation token (negTokenInit) contains two security mechanisms
 with :
      mechType = GSS-MECH1 or
      mechType = GSS-MECH2
      mechToken = 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 (negTokenInit) from (I)
 (T) invokes GSS_Accept_sec_context() with :
 Input
      input_token = negTokenInit
 Output
      major_status = GSS_S_CONTINUE_NEEDED
      output_token = negTokenTarg
 The negotiation token (negTokenTarg) contains :
      negResult = accept (the negotiation result)
      supportedMech : mechType = GSS-MECH1
      mechToken = output_token from
                       GSS_Accept_sec_context(mechToken )
 (T) returns the negotiation token (negTokenTarg) to (I)
 (I) invokes GSS_Init_sec_context() with :
 Input
      input_token = negTokenTarg

Baize & Pinkas Standards Track [Page 13] RFC 2478 GSS-API Negotiation Mechanism December 1998

 Output
      major_status = GSS_S_COMPLETE or GSS_S_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].  As described above in
 section 5.2, the output tokens from the security mechanisms are
 encapsulated in a NegTokenTarg message (with the negResult and
 supportedMech fields omitted, and the mechListMIC included with the
 last token).

5. SECURITY CONSIDERATIONS

 When the mechanism selected by the target from the list supplied by
 the initiator supports integrity protection, then the negotiation is
 protected.
 When one of 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. In particular, an active attacker
 can force to use a security mechanism which is not the common
 preferred one (when multiple security mechanisms are shared between
 peers) but which is acceptable anyway to the target.
 In any case, the communicating peers may be exposed to the denial of
 service threat.

6. ACKNOWLEDGMENTS

 Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of
 Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum
 Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for
 reviewing earlier versions of this document and for providing useful
 inputs. Acknowledgments are also due to Peter Brundrett of Microsoft
 for his proposal for an optimistic negotiation, and for Bill
 Sommerfeld of Epilogue Technology for his proposal for protecting the
 negotiation.

Baize & Pinkas Standards Track [Page 14] RFC 2478 GSS-API Negotiation Mechanism December 1998

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
 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_Set_neg_mechs call

 Input:
      cred_handle          CREDENTIAL HANDLE
                           - NULL specifies default credentials
      mech_set             SET OF OBJECT IDENTIFIER
 Outputs:
      major_status INTEGER,
      minor_status INTEGER,
 Return major_status codes :
   GSS_S_COMPLETE indicates that the set of security mechanisms
   available for negotiation has been set to mech_set. GSS_S_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 mechanisms that may be
 negotiated with the credential identified by cred_handle. This call
 is intended for support of specialised callers who need to restrict
 the set of negotiable security mechanisms from the set of all
 security mechanisms available to the caller (based on available
 credentials). Note that if more than one mechanism is specified in
 mech_set, the order in which those mechanisms are specified implies a
 relative mechanism preference for the target.

Baize & Pinkas Standards Track [Page 15] RFC 2478 GSS-API Negotiation Mechanism December 1998

A.2. GSS_Get_neg_mechs call

 Input:
      cred_handle    CREDENTIAL HANDLE
                     - NULL specifies default credentials
 Outputs:
      major_status INTEGER,
      minor_status INTEGER,
      mech_set     SET OF OBJECT IDENTIFIER
 Return major_status codes :
      GSS_S_COMPLETE indicates that the set of security mechanisms
      available for negotiation has been returned in
      mech_option_set.
      GSS_S_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 mechanisms available
 for negotiation with the credential identified by cred_handle. This
 call is intended for support of specialised callers who need to
 reduce the set of negotiable security mechanisms 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 has no
 input parameter, the returned set is not necessarily available for
 all credentials.

REFERENCES

 [1] Linn, J., "Generic Security Service Application Program
     Interface", RFC 2078, January 1997.
 [2] Standard ECMA-206, "Association Context Management including
     Security Context Management", December 1993.  Available on
     http://www.ecma.ch

Baize & Pinkas Standards Track [Page 16] RFC 2478 GSS-API Negotiation Mechanism December 1998

AUTHORS' ADDRESSES

 Eric Baize
 Bull - 300 Concord Road
 Billerica, MA 01821 - USA
 Phone: +1 978 294 61 37
 Fax: +1 978 294 61 09
 EMail: Eric.Baize@bull.com
 Denis Pinkas
 Bull
 Rue Jean-Jaures
 BP 68
 78340 Les Clayes-sous-Bois - FRANCE
 Phone: +33 1 30 80 34 87
 Fax: +33 1 30 80 33 21
 EMail: Denis.Pinkas@bull.net

Baize & Pinkas Standards Track [Page 17] RFC 2478 GSS-API Negotiation Mechanism December 1998

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Baize & Pinkas Standards Track [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2478.txt · Last modified: 1998/12/18 00:24 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki