Edit File: draft-ietf-sasl-gssapi-xx.txt
SASL Working Group A. Melnikov Internet-Draft Isode Expires: May 22, 2004 November 22, 2003 SASL GSSAPI mechanisms draft-ietf-sasl-gssapi-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 May 22, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 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 May 22, 2004 [Page 1] Internet-Draft SASL GSSAPI mechanisms November 2003 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 . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Melnikov Expires May 22, 2004 [Page 2] Internet-Draft SASL GSSAPI mechanisms November 2003 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 May 22, 2004 [Page 3] Internet-Draft SASL GSSAPI mechanisms November 2003 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 May 22, 2004 [Page 4] Internet-Draft SASL GSSAPI mechanisms November 2003 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 May 22, 2004 [Page 5] Internet-Draft SASL GSSAPI mechanisms November 2003 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 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, encoded according to Melnikov Expires May 22, 2004 [Page 6] Internet-Draft SASL GSSAPI mechanisms November 2003 the application profile specification. The authorization identity is not NUL-terminated. 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. 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 must verify that the src_name is authorized to authenticate as the authorization identity. After these verifications, the authentication process is complete. Melnikov Expires May 22, 2004 [Page 7] Internet-Draft SASL GSSAPI mechanisms November 2003 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 May 22, 2004 [Page 8] Internet-Draft SASL GSSAPI mechanisms November 2003 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 Author/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 Author/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. Melnikov Expires May 22, 2004 [Page 9] Internet-Draft SASL GSSAPI mechanisms November 2003 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 Author/Change controller: iesg@ietf.org Melnikov Expires May 22, 2004 [Page 10] Internet-Draft SASL GSSAPI mechanisms November 2003 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. Melnikov Expires May 22, 2004 [Page 11] Internet-Draft SASL GSSAPI mechanisms November 2003 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 May 22, 2004 [Page 12] Internet-Draft SASL GSSAPI mechanisms November 2003 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(rev)] Melnikov, A., "Simple Authentication and Security Layer (SASL)", draft-ietf-sasl-rfc2222bis (work in progress), October 2003. [SPNEGO] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998. Melnikov Expires May 22, 2004 [Page 13] Internet-Draft SASL GSSAPI mechanisms November 2003 Informative References [SPKM1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 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 May 22, 2004 [Page 14] Internet-Draft SASL GSSAPI mechanisms November 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Melnikov Expires May 22, 2004 [Page 15]