draft-ietf-sasl-gs2-06.txt   draft-ietf-sasl-gs2-07.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Intended status: Standards Track Intended status: Standards Track
Expires: August 10, 2007 Expires: September 1, 2007
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-06 draft-ietf-sasl-gs2-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 10, 2007. This Internet-Draft will expire on September 1, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes how to use a Generic Security Service This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework. This is done by Authentication and Security Layer (SASL) framework. This is done by
skipping to change at page 6, line 12 skipping to change at page 6, line 12
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
3. Mechanism name 3. Mechanism name
3.1. Generating SASL mechanism names from GSS-API OIDs 3.1. Generating SASL mechanism names from GSS-API OIDs
The SASL mechanism name for a GSS-API mechanism is the concatenation The SASL mechanism name for a GSS-API mechanism is the concatenation
of the string "GS2-" and the Base32 encoding [6] (with an upper case of the string "GS2-" and the Base32 encoding [6] (with an upper case
alphabet) of the first ten bytes of the binary SHA-1 hash [4] string alphabet) of the first ten bytes of the binary SHA-1 hash [4] string
computed over the ASN.1 DER encoding [8], including the tag and computed over the ASN.1 DER encoding [7], including the tag and
length octets, of the GSS-API mechanism's Object Identifier. The length octets, of the GSS-API mechanism's Object Identifier. The
Base32 rules on padding characters and characters outside of the Base32 rules on padding characters and characters outside of the
base32 alphabet are not relevant to this use of Base32. If any base32 alphabet are not relevant to this use of Base32. If any
padding or non-alphabet characters are encountered, the name is not a padding or non-alphabet characters are encountered, the name is not a
GS2 family mechanism name. GS2 family mechanism name.
3.2. Computing mechanism names manually 3.2. Computing mechanism names manually
The SASL mechanism name may be computed manually. This is useful The SASL mechanism name may be computed manually. This is useful
when the set of supported GSS-API mechanisms is known in advance. It when the set of supported GSS-API mechanisms is known in advance. It
skipping to change at page 15, line 28 skipping to change at page 15, line 28
Implementations SHOULD set the "client_cbqops" and "server_cbqops" to Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
no security layer and instead depend on the session security afforded no security layer and instead depend on the session security afforded
by the bound-in channel. by the bound-in channel.
Use of no SASL security layers in combination with channel binding Use of no SASL security layers in combination with channel binding
should provide better performance than using SASL security layers should provide better performance than using SASL security layers
over secure channels, and better security characteristics than using over secure channels, and better security characteristics than using
no SASL security layers over secure channels without channel binding. no SASL security layers over secure channels without channel binding.
For more discussions of channel bindings, and the syntax of the For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [7]. channel binding data for various security protocols, see [8]. For
easy reference, the channel binding format used for The Transport
Layer Security (TLS) Protocol [14] is specified in [16].
6. Protocol Overview 6. Protocol Overview
This section describe several high-level protocol exchanges. The This section describe several high-level protocol exchanges. The
descriptions do not assume any properties of the actual GSS-API descriptions do not assume any properties of the actual GSS-API
mechanism. Protocol profiles, GSS-API mechanism specific behaviour, mechanism. Protocol profiles, GSS-API mechanism specific behaviour,
and to some extent implementation and policy choices, will dictate and to some extent implementation and policy choices, will dictate
which packets are sent in what order. The protocol exchanges are which packets are sent in what order. The protocol exchanges are
examples and other exchanges are permitted and will occur. examples and other exchanges are permitted and will occur.
skipping to change at page 25, line 27 skipping to change at page 25, line 27
11.2. Resolving the problem 11.2. Resolving the problem
If the Kerberos V5 mechanism is supported under GS2 in a server, the If the Kerberos V5 mechanism is supported under GS2 in a server, the
server SHOULD also support Kerberos V5 through the "GSSAPI" server SHOULD also support Kerberos V5 through the "GSSAPI"
mechanism, to avoid interoperability problems with older clients. mechanism, to avoid interoperability problems with older clients.
Reasons for violating this recommendation may include security Reasons for violating this recommendation may include security
considerations regarding the absent features in the GS2 mechanism. considerations regarding the absent features in the GS2 mechanism.
The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
could enable certain tunnel attacks [17]. could enable certain tunnel attacks [18].
11.3. Additional recommendations 11.3. Additional recommendations
It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
rather than through the "GSSAPI" mechanism, if both are available, rather than through the "GSSAPI" mechanism, if both are available,
because of the additional features in the GS2 mechanism. because of the additional features in the GS2 mechanism.
12. Mechanisms that negotiate other mechanisms 12. Mechanisms that negotiate other mechanisms
A GSS-API mechanism that negotiate other mechanisms interact badly A GSS-API mechanism that negotiate other mechanisms interact badly
skipping to change at page 26, line 36 skipping to change at page 26, line 36
when it ideally should have used mechanism Y. For this reason, the when it ideally should have used mechanism Y. For this reason, the
use of GSS-API mechanisms that negotiate other mechanisms are use of GSS-API mechanisms that negotiate other mechanisms are
disallowed under GS2. disallowed under GS2.
12.3. Resolving the problems 12.3. Resolving the problems
GSS-API mechanisms that negotiate other mechanisms MUST NOT be used GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. This specifically exclude negotiating with the GS2 SASL mechanism. This specifically exclude negotiating
SPNEGO [11] under GS2. SPNEGO [11] under GS2.
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [16] The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [17]
can be used to identify such mechanisms. can be used to identify such mechanisms.
13. IANA Considerations 13. IANA Considerations
The IANA is advised that SASL mechanism names starting with "GS2-" The IANA is advised that SASL mechanism names starting with "GS2-"
are reserved for SASL mechanisms which conform to this document. The are reserved for SASL mechanisms which conform to this document. The
IANA is directed to place a statement to that effect in the sasl- IANA is directed to place a statement to that effect in the sasl-
mechanisms registry. mechanisms registry.
Subject: Registration of SASL mechanism GS2-* Subject: Registration of SASL mechanism GS2-*
skipping to change at page 28, line 7 skipping to change at page 28, line 7
Security considerations: RFC [THIS-DOC] Security considerations: RFC [THIS-DOC]
Published specification: RFC [THIS-DOC] Published specification: RFC [THIS-DOC]
Person & email address to contact for further information: Person & email address to contact for further information:
Simon Josefsson <simon@josefsson.org> Simon Josefsson <simon@josefsson.org>
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: iesg@ietf.org Owner/Change controller: iesg@ietf.org
Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
14. Security Considerations 14. Security Considerations
Security issues are discussed throughout this memo.
The security provided by GS2 depends on the security provided by the The security provided by GS2 depends on the security provided by the
GSS-API mechanism. If the mechanism do not provide integrity GSS-API mechanism. If the mechanism do not provide integrity
protection, the authorization identity can be replaced by a man in protection, the authorization identity can be replaced by a man in
the middle, and channel bindings and security layers cannot be the middle, and channel bindings and security layers cannot be
negotiated. Therefor, it is generally recommended against using any negotiated. Therefor, it is generally recommended against using any
GSS-API mechanism widely on the Internet that do not support GSS-API mechanism widely on the Internet that do not support
integrity. integrity.
Because the negotiation of a GSS-API mechanism may be done in the Because the negotiation of a particular GSS-API mechanism may be done
clear, it is important for the GSS-API mechanisms to be designed such in the clear, it is important for the GSS-API mechanisms to be
that an active attacker cannot obtain an authentication with weaker designed such that an active attacker cannot obtain an authentication
security properties by modifying the challenges and responses. with weaker security properties by modifying the challenges and
responses. This is a generic design critera for the GSS-API
mechanisms used under GS2.
When a server or client supports multiple GSS-API mechanisms, each of When a server or client supports multiple GSS-API mechanisms, each of
which has a different security strength, it is possible for an active which has a different security strength, it is possible for an active
attacker to cause a party to use the least secure mechanism attacker to cause a party to use the least secure mechanism
supported. There are several ways to mitigate this problem: supported. There are several ways to mitigate this problem:
1. Integrity protected transports can be used, e.g., TLS [14]. To 1. Integrity protected transports can be used, e.g., TLS [14]. To
protect against certain tunnel attacks [17] with that solution, protect against certain tunnel attacks [18], the GSS-API
the GSS-API mechanisms has to support integrity to provide mechanism need to support integrity to provide support for
support for channel bindings channel bindings.
2. A client or server which supports mechanisms of different 2. A client or server which supports mechanisms of different
strengths should have a configurable minimum strength that it strengths should have a configurable minimum strength that it
will use. It is not sufficient for this minimum strength check will use. It is not sufficient for this minimum strength check
to only be on the server, since an active attacker can change to only be on the server, since an active attacker can change
which mechanisms the client sees as being supported, causing the which mechanisms the client sees as being supported, causing the
client to send authentication credentials for its weakest client to send authentication credentials for its weakest
supported mechanism. supported mechanism. This solution, however, is not guaranteed
to the lead to the mutually most secure mechanism, and is
therefor only recommended as an additional precaution.
3. Specify how to use the SPNEGO mechanism in SASL. 3. Specify how to use the SPNEGO mechanism in SASL.
The channel binding is sent without privacy protection and knowledge The channel binding is sent without privacy protection and knowledge
of it is assumed to provide no advantage to an attacker. This is a of it is assumed to provide no advantage to an attacker. This is a
property that has to be considered when specifying channel bindings property that has to be considered when specifying channel bindings
for a security protocol that will be used with GS2. for a security protocol that will be used with GS2.
When constructing the input_name_string, the client should not When constructing the input_name_string, the client should not
canonicalize the server's fully qualified domain name using an canonicalize the server's fully qualified domain name using an
insecure or untrusted directory service, such as the Domain Name insecure or untrusted directory service, such as the Domain Name
System [9] without DNSSEC [15]. System [9] without DNSSEC [15].
GS2 hard code the use of the SHA-1 algorithm to compute the mechanism The GS2 protocol hard code the SHA-1 algorithm for computing the
names, and it is not possible to negotiate the use of other hash mechanism names. It is not possible to negotiate another hash
algorithms. However, no traditional cryptographic hash properties algorithm. However, no traditional cryptographic hash properties
(such as collision resistance or pre-image resistance) are required (such as collision resistance or pre-image resistance) are required
nor assumed. The required and assumed property is that it is nor assumed. The required and assumed property is that it is
statistically unlikely that two different DER-encoded OID's share the statistically unlikely that two different DER-encoded OID's share the
same first 10 octets of the SHA-1 value. same first 10 octets of the SHA-1 value. It is possible to
practically confirm that the SHA-1 algorithm has the necessary
property, by testing many different inputs.
Additional security considerations are in the SASL and GSSAPI Additional security considerations are in the SASL and GSSAPI
specifications. Additional security considerations for the Kerberos specifications. Additional security considerations for the Kerberos
V5 GSSAPI mechanism can be found in [10]. We stress that service V5 GSSAPI mechanism can be found in [10]. We stress that service
names should not be canonicalized using an unsecured directory names should not be canonicalized using an unsecured directory
service such as the DNS without DNSSEC. service such as the DNS without DNSSEC. Security issues are also
discussed throughout this memo.
15. Acknowledgements 15. Acknowledgements
This document is a revision of RFC 2222. This version was derived The history of GS2 can be traced to the GSSAPI mechanism described in
from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov RFC 2222. The GSSAPI mechanism had some drawbacks, which created a
with significant contributions from John G. Myers, although the need for an improved version. This document was derived from
majority of this document has been rewritten by the current author. draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
significant contributions from John G. Myers, although the majority
of this document has been rewritten by the current author.
Contributions of many members of the SASL mailing list are gratefully Contributions of many members of the SASL mailing list are gratefully
acknowledged. In particular, ideas and feedback from Sam Hartman, acknowledged. In particular, ideas and feedback from Sam Hartman,
Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu
improved the document and the protocol. improved the document and the protocol.
16. References 16. References
16.1. Normative References 16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Melnikov, A. and K. Zeilenga, "Simple Authentication and [2] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[3] Linn, J., "Generic Security Service Application Program [3] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [4] National Institute of Standards and Technology, "Secure Hash
RFC 3174, September 2001. Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 4648, October 2006. RFC 4648, October 2006.
[7] Williams, N., "On the Use of Channel Bindings to Secure [7] International Telecommunications Union, "Information Technology
Channels", draft-ietf-nfsv4-channel-bindings-04 (work in - ASN.1 encoding rules: Specification of Basic Encoding Rules
progress), June 2006. (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.
[8] International Organization for Standardization, "Information [8] Williams, N., "On the Use of Channel Bindings to Secure
Processing Systems - Open Systems Interconnection - Channels", draft-williams-on-channel-binding-00 (work in
Specification of Abstract Syntax Notation One (ASN.1)", progress), August 2006.
ISO Standard 8824, December 1990.
16.2. Informative References 16.2. Informative References
[9] Mockapetris, P., "Domain names - concepts and facilities", [9] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, [10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996. June 1996.
[11] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The [11] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
skipping to change at page 32, line 13 skipping to change at page 32, line 15
[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, October 1996. RFC 2025, October 1996.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006. Protocol Version 1.1", RFC 4346, April 2006.
[15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [15] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[16] Williams, N., "Extended Generic Security Service Mechanism [16] Altman, J. and N. Williams, "On the Use of Channel Bindings to
Secure Channels", draft-altman-tls-channel-bindings-01 (work in
progress), December 2006.
[17] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work
in progress), October 2005. in progress), October 2005.
[17] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in [18] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in
Tunneled Authentication", Tunneled Authentication",
WWW http://www.saunalahti.fi/~asokan/research/mitm.html. WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
Author's Address Author's Address
Simon Josefsson Simon Josefsson
Email: simon@josefsson.org Email: simon@josefsson.org
Full Copyright Statement Full Copyright Statement
 End of changes. 20 change blocks. 
37 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/