SASL A. Melnikov
Internet-Draft Isode
Expires: March 7, 2006 September 3, 2005
SASL GSSAPI mechanisms
draft-ietf-sasl-gssapi-03
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 March 7, 2006.
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] KERBEROS V5 and SPNEGO 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 March 7, 2006 [Page 1]
Internet-Draft SASL GSSAPI mechanisms September 2005
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . . 3
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
3. Specification common to both Kerberos V5 and SPNEGO GSSAPI
mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Client side of authentication protocol exchange . . . . . 5
3.2 Server side of authentication protocol exchange . . . . . 6
3.3 Security layer . . . . . . . . . . . . . . . . . . . . . . 7
4. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Melnikov Expires March 7, 2006 [Page 2]
Internet-Draft SASL GSSAPI mechanisms September 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 March 7, 2006 [Page 3]
Internet-Draft SASL GSSAPI mechanisms September 2005
2. Introduction and Overview
This specification documents currently deployed Kerberos V5 and
SPNEGO GSSAPI mechanisms used within SASL. The basic description is
common between the two and is described in Section 3. The described
authentication sequence has known limitations that will be addressed
by a separate document, in particular lack of channel bindings and
the number of round trips required to complete authentication
exchange.
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 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.
Melnikov Expires March 7, 2006 [Page 4]
Internet-Draft SASL GSSAPI mechanisms September 2005
3. Specification common to both Kerberos V5 and SPNEGO GSSAPI
mechanisms
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.
3.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
able to receive, and the remaining octets containing the UTF-8 [UTF8]
encoded authorization identity. (Implementation note: the
Melnikov Expires March 7, 2006 [Page 5]
Internet-Draft SASL GSSAPI mechanisms September 2005
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.
3.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 act as the
authorization identity. After these verifications, the
authentication process is complete.
Melnikov Expires March 7, 2006 [Page 6]
Internet-Draft SASL GSSAPI mechanisms September 2005
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 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 March 7, 2006 [Page 7]
Internet-Draft SASL GSSAPI mechanisms September 2005
4. 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 March 7, 2006 [Page 8]
Internet-Draft SASL GSSAPI mechanisms September 2005
5. IANA Considerations
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 March 7, 2006 [Page 9]
Internet-Draft SASL GSSAPI mechanisms September 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 March 7, 2006 [Page 10]
Internet-Draft SASL GSSAPI mechanisms September 2005
7. Acknowledgements
This document replaces section 7.2 of RFC 2222 [SASL] 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 March 7, 2006 [Page 11]
Internet-Draft SASL GSSAPI mechanisms September 2005
8. References
8.1 Normative References
[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.
[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 3629, November 2003.
8.2 Informative References
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 March 7, 2006 [Page 12]
Internet-Draft SASL GSSAPI mechanisms September 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 March 7, 2006 [Page 13]
