[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4752

SASL Working Group                                           A. Melnikov
Internet-Draft                                                     Isode
Expires: September 27, 2005                               March 29, 2005


                         SASL GSSAPI mechanisms
                       draft-ietf-sasl-gssapi-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 27, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Simple Authentication and Security Layer [SASL] is a method for
   adding authentication support to connection-based protocols.  This
   document describes the method for using the Generic Security Service
   Application Program Interface [GSSAPI] in the Simple Authentication
   and Security Layer [SASL].

   This document replaces section 7.2 of RFC 2222 [SASL], the definition
   of the "GSSAPI" SASL mechanism.



Melnikov               Expires September 27, 2005               [Page 1]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


Table of Contents

   1.  Conventions Used in this Document  . . . . . . . . . . . . . .  3
   2.  Introduction and Overview  . . . . . . . . . . . . . . . . . .  4
     2.1   Example  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Specification common to all GSSAPI mechanisms  . . . . . . . .  6
     4.1   Client side of authentication protocol exchange  . . . . .  6
     4.2   Server side of authentication protocol exchange  . . . . .  7
     4.3   Security layer . . . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 12
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 12
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14

































Melnikov               Expires September 27, 2005               [Page 2]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


1.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [KEYWORDS].














































Melnikov               Expires September 27, 2005               [Page 3]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


2.  Introduction and Overview

   Each and every GSSAPI mechanism used within SASL is implicitly
   registered by this specification.

   For backwards compatibility with existing implementations of Kerberos
   V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5
   GSSAPI mechanism [KRB5GSS] is "GSSAPI" and the SASL mechanism for the
   SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO".  The SASL mechanism
   name for any other GSSAPI mechanism is the concatenation of "GSS-"
   and the Base32 [BASE-ENCODING] encoding of the first ten bytes of the
   MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI
   mechanism's OID.  The Base32 rules on padding characters and
   characters outside of the base32 alphabet are not relevant to this
   use of Base32.

   SASL mechanism names starting with "GSS-" are reserved for SASL
   mechanisms which conform to this document.

   The specification of all SASL mechanisms conforming to this document
   is in the "Specification common to all GSSAPI mechanisms" section of
   this document.

   The IESG is considered to be the owner of all SASL mechanisms which
   conform to this document.  This does NOT necessarily imply that the
   IESG is considered to be the owner of the underlying GSSAPI
   mechanism.

2.1  Example

   The OID for the SPKM-1 mechanism [SPKM1] is 1.3.6.1.5.5.1.  The ASN.1
   DER encoding of this OID is 06 06 2b 06 01 05 05 01.  The MD5 hash of
   the ASN.1 DER encoding is 57 ee 81 82 4e ac 4d b0 e6 50 9f 60 1f 46
   8a 30.  The Base32 encoding of the first ten bytes of this is
   "K7XIDASOVRG3BZSQ".  Thus the SASL mechanism name for the SPKM-1
   GSSAPI mechanism is "GSS-K7XIDASOVRG3BZSQ".















Melnikov               Expires September 27, 2005               [Page 4]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


3.  SPNEGO

   Use of the Simple and Protected GSS-API Negotiation Mechanism
   [SPNEGO] underneath SASL introduces subtle interoperability problems
   and security considerations.  To address these, this section places
   additional requirements on implementations which support SPNEGO
   underneath SASL.

   A client which supports, for example, the Kerberos V5 GSSAPI
   mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
   mechanism will not interoperate with a server which supports the
   Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
   mechanism.

   Since SASL is capable of negotiating amongst GSSAPI mechanisms, the
   only reason for a server or client to support the "GSS-SPNEGO"
   mechanism is to allow a policy of only using mechanisms below a
   certain strength if those mechanism's negotiation is protected.  In
   such a case, a client or server would only want to negotiate those
   weaker mechanisms through SPNEGO.  In any case, there is no down-
   negotiation security consideration with using the strongest mechanism
   and set of options the implementation supports, so for
   interoperability that mechanism and set of options MUST be negotiable
   without using the "GSS-SPNEGO" mechanism.

   If a client's policy is to first prefer GSSAPI mechanism X, then
   non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server
   supports mechanisms Y and Z but not X, then if the client attempts to
   negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
   may end up using mechanism Z when it should have used mechanism Y.
   For this reason, implementations MUST exclude from SPNEGO those
   GSSAPI mechanisms which are weaker than the strongest non-GSSAPI SASL
   mechanism advertised by the server.


















Melnikov               Expires September 27, 2005               [Page 5]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


4.  Specification common to all GSSAPI mechanisms

   Each SASL mechanism which uses a GSSAPI mechanism uses the following
   specification.

   The implementation MAY set any GSSAPI flags or arguments not
   mentioned in this specification as is necessary for the
   implementation to enforce its security policy.

4.1  Client side of authentication protocol exchange

   The client calls GSS_Init_sec_context, passing in
   input_context_handle of 0 (initially), mech_type of the GSSAPI
   mechanism for which this SASL mechanism is registered, chan_binding
   of NULL, and targ_name equal to output_name from GSS_Import_Name
   called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and
   input_name_string of "service@hostname" where "service" is the
   service name specified in the protocol's profile, and "hostname" is
   the fully qualified host name of the server.  If the client will be
   requesting a security layer, it MUST also supply to the
   GSS_Init_sec_context a mutual_req_flag of TRUE, a sequence_req_flag
   of TRUE, and an integ_req_flag of TRUE.  If the client will be
   requesting a security layer providing confidentiality protection, it
   MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE.
   The client then responds with the resulting output_token.  If
   GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
   should expect the server to issue a token in a subsequent challenge.
   The client must pass the token to another call to
   GSS_Init_sec_context, repeating the actions in this paragraph.

   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
   the context to ensure that it provides a level of protection
   permitted by the client's security policy.  If the context is
   acceptable, the client takes the following actions: If the last call
   to GSS_Init_sec_context returned an output_token, then the client
   responds with the output_token, otherwise the client responds with no
   data.  The client should then expect the server to issue a token in a
   subsequent challenge.  The client passes this token to GSS_Unwrap and
   interprets the first octet of resulting cleartext as a bit-mask
   specifying the security layers supported by the server and the second
   through fourth octets as the network byte order maximum size
   output_message to send to the server (if the resulting cleartext is
   not 4 octets long, the client fails the negotiation).  The client
   verifies that the server maximum buffer is 0 if the server doesn't
   advertise support for any security layer.  The client then constructs
   data, with the first octet containing the bit-mask specifying the
   selected security layer, the second through fourth octets containing
   in network byte order the maximum size output_message the client is



Melnikov               Expires September 27, 2005               [Page 6]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


   able to receive, and the remaining octets containing the UTF-8 [UTF8]
   encoded authorization identity.  (Implementation note: the
   authorization identity is not terminated with the NUL (%x00)
   character).  The client passes the data to GSS_Wrap with conf_flag
   set to FALSE, and responds with the generated output_message.  The
   client can then consider the server authenticated.

4.2  Server side of authentication protocol exchange

   The server passes the initial client response to
   GSS_Accept_sec_context as input_token, setting input_context_handle
   to 0 (initially), mech_type of the GSSAPI mechanism for which this
   SASL mechanism is registered, chan_binding of NULL, and
   acceptor_cred_handle equal to output_cred_handle from
   GSS_Acquire_cred called with desired_name equal to output_name from
   GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
   and input_name_string of "service@hostname" where "service" is the
   service name specified in the protocol's profile, and "hostname" is
   the fully qualified host name of the server.  If
   GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server
   returns the generated output_token to the client in challenge and
   passes the resulting response to another call to
   GSS_Accept_sec_context, repeating the actions in this paragraph.

   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.  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 doesn't
   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 network byte
   order maximum size output_message to send to the client, 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



Melnikov               Expires September 27, 2005               [Page 7]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


   authenticate as the authorization identity.  After these
   verifications, the authentication process is complete.

4.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 which are not
   understood must be negotiated off.

   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.
































Melnikov               Expires September 27, 2005               [Page 8]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


5.  IANA Considerations

   The IANA is advised that SASL mechanism names starting with "GSS-"
   are reserved for SASL mechanisms which conform to this document.  The
   IANA is directed to place a statement to that effect in the
   sasl-mechanisms registry.
   Family of SASL mechanisms: YES
   Prefix: GSS-
   Security considerations: RFC [THIS-DOC]
   Published Specification: RFC [THIS-DOC]
   Person & email address to contact for further information: Alexey
      Melnikov <Alexey.Melnikov@isode.com>
   Intended usage: COMMON
   Owner/Change controller: iesg@ietf.org


   The IANA is directed to modify the existing registration for "GSSAPI"
   as follows:
   Family of SASL mechanisms: NO
   SASL mechanism name: GSSAPI
   Security considerations: ?
   Published Specification: RFC [THIS-DOC]
   Person & email address to contact for further information: Alexey
      Melnikov <Alexey.Melnikov@isode.com>
   Intended usage: COMMON
   Owner/Change controller: iesg@ietf.org
   Additional Information: This mechanism is for the Kerberos V5
      mechanism of GSSAPI.  Other GSSAPI mechanisms use other SASL
      mechanism names, as described in this mechanism's published
      specification.


   The IANA is directed to modify the existing registration for
   "GSS-SPNEGO" as follows:
   Family of SASL mechanisms: NO
   SASL mechanism name: GSS-SPNEGO
   Security considerations: See the "SPNEGO" section of RFC [THIS-DOC].
   Published Specification: RFC [THIS-DOC]
   Person & email address to contact for further information: Alexey
      Melnikov <Alexey.Melnikov@isode.com>
   Intended usage: LIMITED USE
   Owner/Change controller: iesg@ietf.org









Melnikov               Expires September 27, 2005               [Page 9]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


6.  Security Considerations

   Security issues are discussed throughout this memo.

   When a server or client supports multiple authentication mechanisms,
   each of which has a different security strength, it is possible for
   an active attacker to cause a party to use the least secure mechanism
   supported.  To protect against this sort of attack, a client or
   server which supports mechanisms of different strengths should have a
   configurable minimum strength that it will use.  It is not sufficient
   for this minimum strength check to only be on the server, since an
   active attacker can change which mechanisms the client sees as being
   supported, causing the client to send authentication credentials for
   its weakest supported mechanism.

   The client's selection of a SASL mechanism is done in the clear and
   may be modified by an active attacker.  It is important for any new
   SASL mechanisms to be designed such that an active attacker cannot
   obtain an authentication with weaker security properties by modifying
   the SASL mechanism name and/or the challenges and responses.

   [SPNEGO] has protection against many of these down-negotiation
   attacks, SASL does not itself have such protection.  The section
   titled "SPNEGO" mentions considerations of choosing negotiation
   through SASL versus SPNEGO.

   The integrity protection provided by the security layer is useless to
   the client unless the client also requests mutual authentication.
   Therefore, a client wishing to benefit from the integrity protection
   of a security layer MUST pass to the GSS_Init_sec_context call a
   mutual_req_flag of TRUE.

   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.

   Additional security considerations are in the [SASL] and [GSSAPI]
   specifications.  Additional security considerations for the GSSAPI
   mechanism can be found in [KRB5GSS].












Melnikov               Expires September 27, 2005              [Page 10]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


7.  Acknowledgements

   This document is a revision of RFC 2222 written by John G.  Myers.
   He also contributed significantly to this revision.

   Thank you to Lawrence Greenfield for converting text of this draft to
   XML format.

   Contributions of many members of the SASL mailing list are gratefully
   acknowledged.









































Melnikov               Expires September 27, 2005              [Page 11]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


8.  References

8.1  Normative References

   [ASN1]     International Organization for Standardization,
              "Information Processing Systems - Open Systems
              Interconnection - Specification of Abstract Syntax
              Notation One (ASN.1)", ISO Standard 8824, December 1990.

   [BASE-ENCODING]
              Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, July 2003.

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

   [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.

   [MD5]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

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

   [SASL[2]]  Melnikov, A., "Simple Authentication and Security Layer
              (SASL)", draft-ietf-sasl-rfc2222bis (work in progress),
              June 2004.

   [SPNEGO]   Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
              Negotiation Mechanism", RFC 2478, December 1998.

   [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

8.2  Informative References

   [SPKM1]  Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
            RFC 2025, October 1996.








Melnikov               Expires September 27, 2005              [Page 12]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


Author's Address

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

   EMail: Alexey.Melnikov@isode.com
   URI:   http://www.melnikov.ca/








































Melnikov               Expires September 27, 2005              [Page 13]

Internet-Draft           SASL GSSAPI mechanisms               March 2005


Intellectual Property Statement

   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
   ietf-ipr@ietf.org.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

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




Melnikov               Expires September 27, 2005              [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/