rfc4752.txt

广泛使用的邮件服务器！同时


RFC 4752                 SASL GSSAPI Mechanism             November 2006


   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
   examines the context to ensure that it provides a level of protection
   permitted by the server's security policy.  In particular, if the
   integ_avail flag is not set in the context, then no security layer
   can be offered or accepted.  If the conf_avail flag is not set in the
   context, then no security layer with confidentiality can be offered
   or accepted.

   If the context is acceptable, the server takes the following actions:
   If the last call to GSS_Accept_sec_context returned an output_token,
   the server returns it to the client in a challenge and expects a
   reply from the client with no data.  Whether or not an output_token
   was returned (and after receipt of any response from the client to
   such an output_token), the server then constructs 4 octets of data,
   with the first octet containing a bit-mask specifying the security
   layers supported by the server and the second through fourth octets
   containing in network byte order the maximum size output_token the
   server is able to receive (which MUST be 0 if the server does not
   support any security layer).  The server must then pass the plaintext
   to GSS_Wrap with conf_flag set to FALSE and issue the generated
   output_message to the client in a challenge.

   The server must then pass the resulting response to GSS_Unwrap and
   interpret the first octet of resulting cleartext as the bit-mask for
   the selected security layer, the second through fourth octets as the
   maximum size output_message the client is able to receive (in network
   byte order), and the remaining octets as the authorization identity.
   The server verifies that the client has selected a security layer
   that was offered and that the client maximum buffer is 0 if no
   security layer was chosen.  The server must verify that the src_name
   is authorized to act as the authorization identity.  After these
   verifications, the authentication process is complete.  The server is
   not expected to return any additional data with the success
   indicator.

3.3.  Security Layer

   The security layers and their corresponding bit-masks are as follows:

          1 No security layer
          2 Integrity protection.
            Sender calls GSS_Wrap with conf_flag set to FALSE
          4 Confidentiality protection.
            Sender calls GSS_Wrap with conf_flag set to TRUE

   Other bit-masks may be defined in the future; bits that are not
   understood must be negotiated off.




Melnikov                    Standards Track                     [Page 6]

RFC 4752                 SASL GSSAPI Mechanism             November 2006


   When decoding any received data with GSS_Unwrap, the major_status
   other than the GSS_S_COMPLETE MUST be treated as a fatal error.

   Note that SASL negotiates the maximum size of the output_message to
   send.  Implementations can use the GSS_Wrap_size_limit call to
   determine the corresponding maximum size input_message.

4.  IANA Considerations

   IANA modified the existing registration for "GSSAPI" as follows:

   Family of SASL mechanisms:  NO

   SASL mechanism name:  GSSAPI

   Security considerations:  See Section 5 of RFC 4752

   Published specification:  RFC 4752

   Person & email address to contact for further information:
      Alexey Melnikov <[e-mail]>

   Intended usage:  COMMON

   Owner/Change controller:  [e-mail]

   Additional information:  This mechanism is for the Kerberos V5
      mechanism of GSS-API.

5.  Security Considerations

   Security issues are discussed throughout this memo.

   When constructing the input_name_string, the client SHOULD NOT
   canonicalize the server's fully qualified domain name using an
   insecure or untrusted directory service.

   For compatibility with deployed software, this document requires that
   the chan_binding (channel bindings) parameter to GSS_Init_sec_context
   and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API
   support for channel bindings.  GSS-API channel bindings in SASL is
   expected to be supported via a new GSS-API family of SASL mechanisms
   (to be introduced in a future document).

   Additional security considerations are in the [SASL] and [GSS-API]
   specifications.  Additional security considerations for the GSS-API
   mechanism can be found in [KRB5GSS] and [KERBEROS].




Melnikov                    Standards Track                     [Page 7]

RFC 4752                 SASL GSSAPI Mechanism             November 2006


6.  Acknowledgements

   This document replaces Section 7.2 of RFC 2222 [RFC2222] by John G.
   Myers.  He also contributed significantly to this revision.

   Lawrence Greenfield converted text of this document to the XML
   format.

   Contributions of many members of the SASL mailing list are gratefully
   acknowledged, in particular comments from Chris Newman, Nicolas
   Williams, Jeffrey Hutzelman, Sam Hartman, Mark Crispin, and Martin
   Rex.

7.  Changes since RFC 2222

   RFC 2078 [RFC2078] specifies the version of GSS-API used by RFC 2222
   [RFC2222], which provided the original version of this specification.
   That version of GSS-API did not provide the integ_integ_avail flag as
   an input to GSS_Init_sec_context.  Instead, integrity was always
   requested.  RFC 4422 [SASL] requires that when possible, the security
   layer negotiation be integrity protected.  To meet this requirement
   and as part of moving from RFC 2078 [RFC2078] to RFC 2743 [GSS-API],
   this specification requires that clients request integrity from
   GSS_Init_sec_context so they can use GSS_Wrap to protect the security
   layer negotiation.  This specification does not require that the
   mechanism offer the integrity security layer, simply that the
   security layer negotiation be wrapped.

8.  References

8.1.  Normative References

   [GSS-API]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [KRB5GSS]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
              1964, June 1996.







Melnikov                    Standards Track                     [Page 8]

RFC 4752                 SASL GSSAPI Mechanism             November 2006


   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
              2005.

   [SASL]     Melnikov, A. and  K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

   [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

8.2.  Informative References

   [RFC2078]  Linn, J., "Generic Security Service Application Program
              Interface, Version 2", RFC 2078, January 1997.

   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

Editor's Address

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   EMail: [e-mail]
   URI:   http://www.melnikov.ca/





















Melnikov                    Standards Track                     [Page 9]

RFC 4752                 SASL GSSAPI Mechanism             November 2006


Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.






Melnikov                    Standards Track                    [Page 10]