rfc2478.txt

RFC 的详细文档！

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: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Denis Pinkas
   Bull
   Rue Jean-Jaures
   BP 68
   78340 Les Clayes-sous-Bois - FRANCE

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]































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]