rfc2478.txt

RFC 的详细文档！


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