Internet Engineering Task Force (IETF) S. Josefsson
Request for Comments: 5801 SJD AB
Category: Standards Track N. Williams
ISSN: 2070-1721 Oracle
July 2010
Using Generic Security Service Application Program Interface (GSS-API)
Mechanisms in Simple Authentication and Security Layer (SASL):
The GS2 Mechanism Family
Abstract
This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the Simple
Authentication and Security Layer (SASL) framework. This is done by
defining a new SASL mechanism family, called GS2. This mechanism
family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of
channel binding. Only GSS-API mechanisms that support channel
binding and mutual authentication are supported.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5801.
Josefsson & Williams Standards Track [Page 1]
RFC 5801 SASL GS2-* July 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Josefsson & Williams Standards Track [Page 2]
RFC 5801 SASL GS2-* July 2010
Table of Contents
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
3. Mechanism Name ..................................................5
3.1. Generating SASL Mechanism Names from GSS-API OIDs ..........5
3.2. Computing Mechanism Names Manually .........................6
3.3. Examples ...................................................6
3.4. Grandfathered Mechanism Names ..............................7
4. SASL Authentication Exchange Message Format .....................8
5. Channel Bindings ...............................................10
5.1. Content of GSS-CHANNEL-BINDINGS Structure .................11
5.2. Default Channel Binding ...................................12
6. Examples .......................................................12
7. Authentication Conditions ......................................14
8. GSS-API Parameters .............................................15
9. Naming .........................................................15
10. GSS_Inquire_SASLname_for_mech Call ............................15
10.1. gss_inquire_saslname_for_mech ............................16
11. GSS_Inquire_mech_for_SASLname Call ............................18
11.1. gss_inquire_mech_for_saslname ............................19
12. Security Layers ...............................................20
13. Interoperability with the SASL GSSAPI Mechanism ...............20
13.1. The Interoperability Problem .............................20
13.2. Resolving the Problem ....................................20
13.3. Additional Recommendations ...............................20
14. GSS-API Mechanisms That Negotiate Other Mechanisms ............21
14.1. The Interoperability Problem .............................21
14.2. Security Problem .........................................21
14.3. Resolving the Problems ...................................21
15. IANA Considerations ...........................................22
16. Security Considerations .......................................22
17. Acknowledgements ..............................................24
18. References ....................................................24
18.1. Normative References .....................................24
18.2. Informative References ...................................25
Josefsson & Williams Standards Track [Page 3]
RFC 5801 SASL GS2-* July 2010
1. Introduction
Generic Security Service Application Program Interface (GSS-API)
[RFC2743] is a framework that provides security services to
applications using a variety of authentication mechanisms. Simple
Authentication and Security Layer (SASL) [RFC4422] is a framework to
provide authentication and security layers for connection-based
protocols, also using a variety of mechanisms. This document
describes how to use a GSS-API mechanism as though it were a SASL
mechanism. This facility is called GS2 -- a moniker that indicates
that this is the second GSS-API->SASL mechanism bridge. The original
GSS-API->SASL mechanism bridge was specified by [RFC2222], now
[RFC4752]; we shall sometimes refer to the original bridge as GS1 in
this document.
All GSS-API mechanisms are implicitly registered for use within SASL
by this specification. The SASL mechanisms defined in this document
are known as the GS2 family of mechanisms.
The GS1 bridge failed to gain wide deployment for any GSS-API
mechanism other than "The Kerberos Version 5 GSS-API Mechanism"
[RFC1964] [RFC4121], and has a number of problems that led us to
desire a new bridge. Specifically, a) GS1 was not round-trip
optimized and b) GS1 did not support channel binding [RFC5056].
These problems and the opportunity to create the next SASL password-
based mechanism, "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms" [RFC5802], as a GSS-API
mechanism used by SASL applications via GS2, provide the motivation
for GS2.
In particular, the current consensus of the SASL community appears to
be that SASL "security layers" (i.e., confidentiality and integrity
protection of application data after authentication) are too complex
and redundant because SASL applications tend to have an option to run
over a Transport Layer Security (TLS) [RFC5246] channel. Use of SASL
security layers is best replaced with channel binding to a TLS
channel.
GS2 is designed to be as simple as possible. It adds to GSS-API
security context token exchanges only the bare minimum to support
SASL semantics and negotiation of use of channel binding.
Specifically, GS2 adds a small header (a few bytes plus the length of
the client-requested SASL authorization identity) to the initial GSS-
API context token and to the application channel binding data. GS2
uses SASL mechanism negotiation to implement channel binding
negotiation. Security-relevant GS2 plaintext is protected via the
use of GSS-API channel binding. Additionally, to simplify the
Josefsson & Williams Standards Track [Page 4]
RFC 5801 SASL GS2-* July 2010
implementation of GS2 mechanisms for implementors who will not
implement a GSS-API framework, we compress the initial security
context token header required by [RFC2743], Section 3.1.
GS2 does not protect any plaintext exchanged outside GS2, such as
SASL mechanism negotiation plaintext, or application messages
following authentication. But using channel binding to a secure
channel over which all SASL and application plaintext is sent will
cause all that plaintext to be authenticated.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The document uses many terms and function names defined in [RFC2743],
as updated by [RFC5554].
3. Mechanism Name
There are two SASL mechanism names for any GSS-API mechanism used
through this facility. One denotes that the server supports channel
binding. The other denotes that it does not.
The SASL mechanism name for a GSS-API mechanism is that which is
provided by that mechanism when it was specified, if one was
specified. This name denotes that the server does not support
channel binding. Add the suffix "-PLUS" and the resulting name
denotes that the server does support channel binding. SASL
implementations can use the GSS_Inquire_SASLname_for_mech call (see
below) to query for the SASL mechanism name of a GSS-API mechanism.
If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
implementation needs some other mechanism to map mechanism Object
Identifiers (OIDs) to SASL names internally. In this case, the
implementation can only support the mechanisms for which it knows the
SASL name. If GSS_Inquire_SASLname_for_mech() fails and the GS2
implementation cannot map the OID to a SASL mechanism name via some
other means, then the GS2 implementation MUST NOT use the given GSS-
API mechanism.
3.1. Generating SASL Mechanism Names from GSS-API OIDs
For GSS-API mechanisms whose SASL names are not defined together with
the GSS-API mechanism or in this document, the SASL mechanism name is
concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
(with an uppercase alphabet) of the first 55 bits of the binary SHA-1
Josefsson & Williams Standards Track [Page 5]
RFC 5801 SASL GS2-* July 2010
hash [FIPS.180-1.1995] string computed over the ASN.1 DER encoding
[CCITT.X690.2002], including the tag and length octets, of the GSS-
API mechanism's Object Identifier. The Base32 rules on padding
characters and characters outside of the Base32 alphabet are not
relevant to this use of Base32. If any padding or non-alphabet
characters are encountered, the name is not a GS2 family mechanism
name. This name denotes that the server does not support channel
binding. Add the suffix "-PLUS" and the resulting name denotes that
the server does support channel binding.
A GS2 mechanism that has a non-OID-derived SASL mechanism name is
said to have a "user-friendly SASL mechanism name".
3.2. Computing Mechanism Names Manually
The hash-derived GS2 SASL mechanism name may be computed manually.
This is useful when the set of supported GSS-API mechanisms is known
in advance. This eliminates the need to implement Base32, SHA-1, and
DER in the SASL mechanism. The computed mechanism name can be used
directly in the implementation, and the implementation need not be
concerned if the mechanism is part of a mechanism family.
3.3. Examples
The OID for the Simple Public-Key GSS-API Mechanism (SPKM-1)
[RFC2025] is 1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID,
including the tag and length, is (in hex) 06 07 2b 06 01 05 05 01 01.
The SHA-1 hash of the ASN.1 DER encoding is (in hex) 1c f8 f4 2b 5a
9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad. Convert the first 7
octets to binary, drop the last bit, and re-group them in groups of
5, and convert them back to decimal, which results in these
computations:
hex:
1c f8 f4 2b 5a 9f 80
binary:
00011100 11111000 11110100 00101011 01011010
10011111 1000000
binary in groups of 5:
00011 10011 11100 01111 01000 01010 11010 11010
10011 11110 00000
decimal of each group:
3 19 28 15 8 10 26 26 19 30 0
Josefsson & Williams Standards Track [Page 6]
RFC 5801 SASL GS2-* July 2010
base32 encoding:
D T 4 P I K 2 2 T 6 A
The last step translates each decimal value using table 3 in Base32
[RFC4648]. Thus, the SASL mechanism name for the SPKM-1 GSSAPI
mechanism is "GS2-DT4PIK22T6A".
The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
93 25 51 6a fc ff 04 b0 43 60. Convert the 7 octets to binary, drop
the last bit, and re-group them in groups of 5, and convert them back
to decimal, which results in these computations:
hex:
82 d2 73 25 76 6b d6
binary:
10000010 11010010 01110011 00100101 01110110
01101011 1101011
binary in groups of 5:
10000 01011 01001 00111 00110 01001 01011 10110
01101 01111 01011
decimal of each group:
16 11 9 7 6 9 11 22 13 15 11
base32 encoding:
Q L J H G J L W N P L
The last step translates each decimal value using table 3 in Base32
[RFC4648]. Thus, the SASL mechanism name for the Kerberos V5 GSS-API
mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism
supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next
section assigns the Kerberos V5 mechanism a non-hash-derived
mechanism name.
3.4. Grandfathered Mechanism Names
Some older GSS-API mechanisms were not specified with a SASL GS2
mechanism name. Using a shorter name can be useful, nonetheless. We
specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5
mechanism, to be used as if the original specification documented it,
see Section 15.
Josefsson & Williams Standards Track [Page 7]