Network Working Group J. Myers Internet Draft March, 1999 Document: draft-ietf-cat-sasl-gssapi-00.txt SASL GSSAPI mechanisms Status of this Memo 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 document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. J. Myers [Page i]
Internet DRAFT SASL March 23, 1999 1. 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 amends section 7.2 of RFC 2222 [SASL], the definition of the "GSSAPI" SASL mechanism. 2. Organization of this Document 2.1. How to Read This Document [TODO: is this section needed?] 2.2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. 2.3. Examples [TODO: No examples included. Needed?] Examples in this document are for the IMAP profile [IMAP4] of this specification. The base64 encoding of challenges and responses, as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of the SASL specification itself. 3. Introduction and Overview Each GSSAPI mechanism used within SASL MUST have a separate SASL mechanism registered. The registration procedure for SASL mechanisms is defined in the base SASL specification [SASL]. For backwards compatibility with existing implementations of Kerberos V5 under SASL, the SASL mechanism name for the Kerberos V5 GSSAPI mechanism is "GSSAPI". The SASL mechanism name for any other GSSAPI mechanism is the concatenation of "GSS-" and the [TODO] of the GSSAPI mechanism. SASL mechanism names starting with "GSS-" are reserved for SASL J. Myers [Page 2]
Internet DRAFT SASL March 23, 1999 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 imply that the IESG is considered to be the owner of the underlying GSSAPI mechanism. 4. SPNEGO Implementations SHOULD NOT use the Simple and Protected GSS-API Negotiation Mechanism [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. 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. One reason a server or client might want to violate the above SHOULD directive is if it has a policy of only using mechanisms below a certain strength if their negotiation is protected. In such a case, it would only want to negotiate those weaker mechnisms 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. 6. Specification common to all GSSAPI mechanisms Each SASL mechanism which uses a GSSAPI mechanism uses the following specification. 6.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, and targ_name equal to output_name from GSS_Import_Name called with input_name_type J. Myers [Page 3]
Internet DRAFT SASL March 23, 1999 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. 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 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 maximum size output_message to send to the server. 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 able to receive, and the remaining octets containing the authorization identity. 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. 6.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). 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 client 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. The server must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE J. Myers [Page 4]
Internet DRAFT SASL March 23, 1999 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 to send to the client, and the remaining octets as the authorization identity. The server must verify that the src_name is authorized to authenticate as the authorization identity. After these verifications, the authentication process is complete. 6.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 Privacy 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. 7. IANA Considerations The IANA is directed to modify the existing registration for "GSSAPI" in the "sasl-mechanisms" so that this document is listed as the published specification. Add the descriptive text "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 advised that SASL mechanism names starting with "GSS-" are reserved for SASL mechanisms which conform to this document. J. Myers [Page 5]
Internet DRAFT SASL March 23, 1999 8. References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 1730, University of Washington, December 1994. [GSSAPI] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997 [GSSAPI-KERBEROS] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997 [SPNEGO] Baize, E., Pinkas., D., "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998 9. 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 [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. Additional security considerations are in the SASL [SASL] and GSSAPI [GSSAPI] specifications. J. Myers [Page 6]
Internet DRAFT SASL March 23, 1999 10. Author's Address John G. Myers Netscape Communications 501 E. Middlefield Road Mail Stop MV-029 Mountain View, CA 94043-4042 Email: jgmyers@netscape.com J. Myers [Page 7]
Internet DRAFT SASL March 23, 1999 Table of Contents Status of this Memo ............................................... i 1. Abstract .................................................... 2 2. Organization of this Document ............................... 2 2.1. How to Read This Document ................................... 2 2.2. Conventions Used in this Document ........................... 2 2.3. Examples .................................................... 2 3. Introduction and Overview ................................... 2 4. SPNEGO ...................................................... 3 6. Specification common to all GSSAPI mechanisms ............... 3 6.1. Client side of authentication protocol exchange ............. 3 6.2. Server side of authentication protocol exchange ............. 4 6.3. Security layer .............................................. 5 7. IANA Considerations ......................................... 5 8. References .................................................. 6 9. Security Considerations ..................................... 6 10. Author's Address ............................................ 7 J. Myers [Page ii]
